├── .gitignore ├── DApp_Development ├── eip │ ├── EIP4377详解.md │ ├── ERC1967详解.md │ ├── ERC1167详解.md │ ├── ERC2535详解.md │ └── EIP1559详解.md ├── 应用场景 │ ├── nft │ │ └── 动态NFT.md │ ├── defi │ │ ├── uniswap │ │ │ └── v2 │ │ │ │ ├── uniswap_v2_部署.md │ │ │ │ └── uniswap_v2_Factory.md │ │ ├── 永续期货合约.md │ │ └── aave │ │ │ └── Avae原理.md │ └── 智能合约可能的业务方向.md ├── 安全审计 │ ├── 合约漏洞 │ │ ├── 拒绝服务攻击.md │ │ ├── 不要在合约中存隐私数据.md │ │ ├── 提案攻击.md │ │ ├── 重放攻击.md │ │ ├── 参阅的大部分资料.md │ │ ├── 算法上下溢出.md │ │ ├── 权限控制漏洞.md │ │ ├── 短地址参数攻击.md │ │ └── 重入攻击手段.md │ └── 安全相关资料.md ├── 合约高级技巧 │ ├── 死磕solidity之可迭代映射.md │ ├── 设计模式 │ │ ├── 生命周期 │ │ │ ├── 允许合约自动停止.md │ │ │ └── 允许合约自毁.md │ │ ├── 安全 │ │ │ ├── speed_bump.md │ │ │ ├── mutex.md │ │ │ ├── Rate Limit.md │ │ │ └── 安全转账.md │ │ ├── 可维护性 │ │ │ ├── contract_relay.md │ │ │ ├── contract_regestry.md │ │ │ └── 数据逻辑分离.md │ │ └── solidity 之设计模式.md │ ├── 合约升级实战.md │ ├── 死磕CREATE2控制合约地址.md │ ├── 事件高级用法.md │ └── 死磕solidity之内存布局.md ├── solidity-tech.md ├── 合约基础 │ ├── solidity_fallback和receive.md │ ├── solidity_create2.md │ ├── solidity_delegatecall.md │ ├── solidity_selector.md │ ├── solidity_staticcall.md │ ├── solidity_callcode.md │ └── solidity_call.md └── 主流链内置合约玩法.md ├── Public_Chain_Development ├── 布隆过滤器.md ├── Cryptography │ ├── 安全多方计算 │ │ ├── 不经意传输协议.md │ │ ├── 参考的资料.md │ │ ├── 同态加密vs多方安全计算协议.md │ │ ├── 混淆电路框架.md │ │ ├── VSS协议.md │ │ ├── 同态加密.md │ │ └── 基于seal的smpc协议.md │ ├── 签名 │ │ ├── 死磕密码学_ECDH算法-1.md │ │ ├── bls签名.md │ │ └── 死磕密码学_ECDSA算法-2.md │ ├── BLS签名算法.md │ ├── 椭圆曲线 │ │ ├── 椭圆曲线学习路线.md │ │ ├── 椭圆曲线_性质及分类 │ │ ├── 椭圆曲线_定义及点加运算.md │ │ └── 椭圆曲线_离散对数问题.md │ ├── 密码学中的数学 │ │ ├── 数论基础 │ │ │ ├── 数论_欧拉定理.md │ │ │ ├── 数论_素数与素数分布.md │ │ │ ├── 数论_整数与除法.md │ │ │ ├── 数论_费马小定理.md │ │ │ └── 数论_模运算.md │ │ ├── 代数基础 │ │ │ ├── 代数_域.md │ │ │ ├── 代数_指数对数.md │ │ │ ├── 代数_集合关系映射.md │ │ │ ├── 代数_多项式.md │ │ │ ├── 代数_常见数.md │ │ │ └── 代数_群.md │ │ └── 密码学中的数学基础.md │ ├── 基础 │ │ ├── 非对称加密.md │ │ ├── 哈希函数.md │ │ ├── 数字签名.md │ │ ├── 完全同态加密.md │ │ └── 对称加密.md │ └── 隐私计算 │ │ ├── VRF │ │ └── VRF详解.md │ │ └── VDF │ │ └── VDF.md ├── P2P_Network │ ├── p2p │ │ ├── 死磕libp2p网络之mdns.md │ │ ├── 死磕p2p网络之传输协议.md │ │ ├── 死磕libp2p之DCUtR.md │ │ ├── 死磕p2p网络之relay协议.md │ │ ├── 死磕libp2p网络之multiAddress.md │ │ ├── 死磕libp2p之安全通信.md │ │ ├── 死磕p2p网络之NAT传输.md │ │ ├── 死磕libp2p网络之autoNAT.md │ │ ├── 死磕Libp2p之circuit relay.md │ │ ├── 死磕libp2p之Peer.md │ │ ├── 死磕libp2p之流复用.md │ │ ├── 死磕libp2p之协议.md │ │ └── 死磕libp2p之传输.md │ └── libp2p源码分析 │ │ └── 死磕libp2p之DHT路由.md ├── Public_Chain_Research │ ├── cosmos │ │ ├── cometBFT │ │ │ ├── ABCI++.md │ │ │ ├── cometBFT架构设计.md │ │ │ └── 死磕cometBFT共识源码.md │ │ ├── ibc │ │ │ ├── ibc-middleware.md │ │ │ ├── interchain-accounts.md │ │ │ ├── ibc原理.md │ │ │ └── cross chain via relayer.md │ │ ├── Cosmos sdk │ │ │ ├── cosmos_grpc.md │ │ │ └── cosmos_init.md │ │ ├── cosmos开发者.md │ │ ├── cosmos源码.md │ │ └── tendermint │ │ │ └── tendermint源码架构.md │ ├── Ethereum │ │ ├── 以太坊基础理论部分 │ │ │ ├── B+Tree和bolt优化leveldb.md │ │ │ ├── merkle tree详解.md │ │ │ ├── verkle tree 详解.md │ │ │ ├── 多项式承诺替换状态根.md │ │ │ ├── 钱包系列 │ │ │ │ ├── 账户抽象化.md │ │ │ │ └── 详解私钥、密码、keystore和助记词.md │ │ │ ├── 2.以太坊相关术语.md │ │ │ ├── 深入理解verkle tree.md │ │ │ ├── 无状态以太坊.md │ │ │ └── 以太坊介绍.md │ │ ├── 以太坊源码分析 │ │ │ ├── 交易缓冲池.xmind │ │ │ ├── downloader.xmind │ │ │ ├── p2p │ │ │ │ ├── P2P广播和同步.xmind │ │ │ │ ├── p2p代码概览.xmind │ │ │ │ ├── p2p源码分析.xmind │ │ │ │ ├── 新区块传播源码.xmind │ │ │ │ ├── p2p模块 2 2 2.xmind │ │ │ │ ├── p2p网络 2 2 2.xmind │ │ │ │ ├── p2p服务启动 2 2 2.xmind │ │ │ │ ├── p2p节点通信 2 2 2.xmind │ │ │ │ ├── 发起TCP连接 2 2 2.xmind │ │ │ │ └── p2p网络RLPX传输协议 2 2 2.xmind │ │ │ ├── 死磕以太坊源码分析之trie-15.md │ │ │ ├── 死磕以太坊源码分析之EVM介绍-18.md │ │ │ └── 死磕以太坊源码分析之EthDB-17.md │ │ ├── 以太坊关键函数全景图（持续更新）.xmind │ │ ├── 生态.md │ │ └── 论文.md │ ├── ton │ │ ├── ton开发 │ │ │ ├── ton开发.md │ │ │ └── NFT.md │ │ └── 资料.md │ └── tendermint │ │ ├── 死磕tendermint源码分析_1.md │ │ └── tendermint.md ├── Consensus_Mechanisms │ ├── Aardvark协议（BFT）.pdf │ ├── BFT 协议整体看法.md │ ├── 死磕共识算法_POS算法-2.md │ ├── istanbul共识源码分析.md │ └── 死磕共识算法_pow算法-1.md └── 数据可用性DA探索 │ └── 数据可用性DA探索.md ├── Layer2_Solutions ├── btclayer2 │ ├── bitvm.md │ └── btclayer2社区资料汇总.md ├── layer2 │ ├── Polygon zkevm │ │ ├── zk-contracts.md │ │ ├── zkevm 代码分析.md │ │ ├── QA和资料.md │ │ ├── polygon zk evm 概述 .md │ │ └── 核心组件.md │ ├── optimism │ │ ├── optimism源码分析 │ │ │ ├── sequencer源码.md │ │ │ ├── 关于optimism的一些架构想法.md │ │ │ ├── 死磕optimism之证明挑战.md │ │ │ ├── 死磕optimism之更新gasprice.md │ │ │ ├── Messenger合约.md │ │ │ ├── optimism目前的问题.md │ │ │ ├── batch-submitter.md │ │ │ ├── 整体理解.md │ │ │ ├── op-technology-stack.md │ │ │ ├── ovm操作.md │ │ │ ├── op-node │ │ │ │ └── op-node.md │ │ │ ├── op搭建避坑.md │ │ │ ├── 死磕optimism之batch提交.md │ │ │ ├── op-存款备份.md │ │ │ └── 死磕optimism之withdraw.md │ │ └── optimism spec分析 │ │ │ ├── op-批量提交.md │ │ │ ├── op-rollupnode.md │ │ │ ├── optimism介绍篇.md │ │ │ └── op-系统配置.md │ ├── arbitrum │ │ ├── 跨链消息.md │ │ └── sequencer.md │ ├── zkroullup │ │ ├── zkrollup资料.md │ │ ├── zkbnb.md │ │ └── zksync2.0.md │ ├── layer2资料.md │ └── celestia │ │ └── celestia简介.md └── b2network │ └── committer.md ├── Privacy_Computing ├── 安全多方计算 │ ├── 秘密分享SSS.md │ ├── 门限签名方案TSS.md │ └── 安全多方计算学习路径.md └── ZK │ └── ZK 资料整理.md ├── Cross_Chain_Technology └── 跨链方案 │ ├── 跨链桥 │ ├── abitrum.md │ ├── hop协议.md │ ├── context协议.md │ ├── optimism gateway .md │ ├── polygon bridge.md │ ├── cbridge.md │ ├── 桥概念.md │ └── multichain.md │ ├── bls算法.doc │ └── 跨链研究文档.pdf ├── Decentralized_Storage ├── FileCoin │ └── 死磕FileCoin_经济模型.md └── IPFS │ ├── 副本libp2p.docx │ └── IPFS学习点.md ├── design_ideas.xmind ├── Learning_Roadmaps_And_Resources ├── 死磕区块链_中阶学习路线图.xmind ├── 死磕区块链_初阶学习路线图.xmind ├── 死磕区块链_高阶学习路线图.xmind └── 相关学习资料（路线图和资料持续更新，建议关注）.md ├── TODO.md └── Blockchain_Basics └── 纠删码.md /.gitignore: -------------------------------------------------------------------------------- 1 | 2 | .DS_Store 3 | -------------------------------------------------------------------------------- /DApp_Development/eip/EIP4377详解.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Public_Chain_Development/布隆过滤器.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /DApp_Development/应用场景/nft/动态NFT.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Layer2_Solutions/btclayer2/bitvm.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Privacy_Computing/安全多方计算/秘密分享SSS.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Cross_Chain_Technology/跨链方案/跨链桥/abitrum.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Cross_Chain_Technology/跨链方案/跨链桥/hop协议.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Cross_Chain_Technology/跨链方案/跨链桥/context协议.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Cross_Chain_Technology/跨链方案/跨链桥/optimism gateway .md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Cross_Chain_Technology/跨链方案/跨链桥/polygon bridge.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/Polygon zkevm/zk-contracts.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/安全多方计算/不经意传输协议.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/sequencer源码.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕libp2p网络之mdns.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /DApp_Development/安全审计/合约漏洞/拒绝服务攻击.md: -------------------------------------------------------------------------------- 1 | https://xz.aliyun.com/t/9871 -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/arbitrum/跨链消息.md: -------------------------------------------------------------------------------- 1 | ## L1 to L2 消息 2 | 3 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/关于optimism的一些架构想法.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/死磕optimism之证明挑战.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /DApp_Development/eip/ERC1967详解.md: -------------------------------------------------------------------------------- 1 | https://eips.ethereum.org/EIPS/eip-1967 -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/死磕optimism之更新gasprice.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/cosmos/cometBFT/ABCI++.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/死磕solidity之可迭代映射.md: -------------------------------------------------------------------------------- 1 | https://eth.antcave.club/4-mapping -------------------------------------------------------------------------------- /Decentralized_Storage/FileCoin/死磕FileCoin_经济模型.md: -------------------------------------------------------------------------------- 1 | > 死磕FileCoin|经济模型 2 | 3 | -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/cosmos/cometBFT/cometBFT架构设计.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/cosmos/ibc/ibc-middleware.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/签名/死磕密码学_ECDH算法-1.md: -------------------------------------------------------------------------------- 1 | > 死磕密码学|ECDH算法 2 | 3 | -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/cosmos/Cosmos sdk/cosmos_grpc.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /DApp_Development/安全审计/合约漏洞/不要在合约中存隐私数据.md: -------------------------------------------------------------------------------- 1 | https://foresightnews.xyz/article/detail/1511 -------------------------------------------------------------------------------- /DApp_Development/应用场景/defi/uniswap/v2/uniswap_v2_部署.md: -------------------------------------------------------------------------------- 1 | ## 官方部署 2 | 3 | ## 快速部署 4 | 5 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/Messenger合约.md: -------------------------------------------------------------------------------- 1 | Messenger合约用于发送和接收来自其他域的消息。 -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/设计模式/生命周期/允许合约自动停止.md: -------------------------------------------------------------------------------- 1 | https://github.com/maxwoe/solidity_patterns.git -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/设计模式/生命周期/允许合约自毁.md: -------------------------------------------------------------------------------- 1 | https://github.com/maxwoe/solidity_patterns.git -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊基础理论部分/B+Tree和bolt优化leveldb.md: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/合约升级实战.md: -------------------------------------------------------------------------------- 1 | https://github.com/NoharaHiroshi/upgradability-solidity-demo.git -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/死磕CREATE2控制合约地址.md: -------------------------------------------------------------------------------- 1 | https://blog.csdn.net/qq_52708261/article/details/127351875 -------------------------------------------------------------------------------- /DApp_Development/安全审计/合约漏洞/提案攻击.md: -------------------------------------------------------------------------------- 1 | https://blog.chain.link/market-manipulation-vs-oracle-exploits-zh/ -------------------------------------------------------------------------------- /design_ideas.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/design_ideas.xmind -------------------------------------------------------------------------------- /DApp_Development/eip/ERC1167详解.md: -------------------------------------------------------------------------------- 1 | https://mirror.xyz/xyyme.eth/mmUAYWFLfcHGCEFg8903SweY3Sl-xIACZNDXOJ3twz8 -------------------------------------------------------------------------------- /DApp_Development/应用场景/defi/永续期货合约.md: -------------------------------------------------------------------------------- 1 | https://github.com/Binance-docs/binance-coin-margined-futures 2 | 3 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/Polygon zkevm/zkevm 代码分析.md: -------------------------------------------------------------------------------- 1 | https://www.bcskill.com/index.php/archives/1818.html -------------------------------------------------------------------------------- /Privacy_Computing/ZK/ZK 资料整理.md: -------------------------------------------------------------------------------- 1 | https://learnblockchain.cn/maps/ZKP![zk图谱](https://p.ipic.vip/5jxji9.jpg) -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/事件高级用法.md: -------------------------------------------------------------------------------- 1 | 事件过滤器 2 | 3 | https://github.com/NoharaHiroshi/upgradability-solidity-demo.git 4 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/zkroullup/zkrollup资料.md: -------------------------------------------------------------------------------- 1 | https://ipfs.io/ipfs/QmUHpp1nkFFeT3eodJHj9V9xWyhnwEpenxHAGYgB7Lzjgw -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕p2p网络之传输协议.md: -------------------------------------------------------------------------------- 1 | - 简单阐述tcp和udp 传输的区别 2 | - 常见的网络传输协议 3 | - 监听和拨号 4 | - P2p 节点的地址格式 -------------------------------------------------------------------------------- /DApp_Development/eip/ERC2535详解.md: -------------------------------------------------------------------------------- 1 | eip2535详解https://www.jianshu.com/p/6d727c6d3e1d 2 | 3 | https://eips.ethereum.org/EIPS/eip-2535 -------------------------------------------------------------------------------- /DApp_Development/安全审计/合约漏洞/重放攻击.md: -------------------------------------------------------------------------------- 1 | https://learnblockchain.cn/article/5030 2 | 3 | 4 | 5 | https://learnblockchain.cn/article/4539 -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊基础理论部分/merkle tree详解.md: -------------------------------------------------------------------------------- 1 | https://kndrck.co/posts/efficient-merkletrees-zk-proofs/ -------------------------------------------------------------------------------- /Cross_Chain_Technology/跨链方案/bls算法.doc: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Cross_Chain_Technology/跨链方案/bls算法.doc -------------------------------------------------------------------------------- /Cross_Chain_Technology/跨链方案/跨链研究文档.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Cross_Chain_Technology/跨链方案/跨链研究文档.pdf -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊基础理论部分/verkle tree 详解.md: -------------------------------------------------------------------------------- 1 | https://blog.ethereum.org/2021/12/02/verkle-tree-structure -------------------------------------------------------------------------------- /Decentralized_Storage/IPFS/副本libp2p.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Decentralized_Storage/IPFS/副本libp2p.docx -------------------------------------------------------------------------------- /DApp_Development/安全审计/合约漏洞/参阅的大部分资料.md: -------------------------------------------------------------------------------- 1 | ![image-20230109093443882](/Users/carver/Library/Application Support/typora-user-images/image-20230109093443882.png) -------------------------------------------------------------------------------- /DApp_Development/应用场景/defi/aave/Avae原理.md: -------------------------------------------------------------------------------- 1 | ## 参考 2 | 3 | > https://github.com/aave/aave-v3-core/blob/master/techpaper/Aave_V3_Technical_Paper.pdf 4 | 5 | -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊基础理论部分/多项式承诺替换状态根.md: -------------------------------------------------------------------------------- 1 | https://ethresear.ch/t/using-polynomial-commitments-to-replace-state-roots/7095 -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/optimism目前的问题.md: -------------------------------------------------------------------------------- 1 | ## sequencer唯一 2 | 3 | 4 | 5 | ## 用户从L2提款至L1时间长 6 | 7 | 8 | ## DA依旧依赖以太坊，成本高 9 | 10 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/安全多方计算/参考的资料.md: -------------------------------------------------------------------------------- 1 | https://blog.csdn.net/jingzi123456789/article/details/105832143 2 | 3 | https://www.openmpc.com/article/169 -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/设计模式/安全/speed_bump.md: -------------------------------------------------------------------------------- 1 | https://github.com/maxwoe/solidity_patterns.git 2 | 3 | https://github.com/NoharaHiroshi/upgradability-solidity-demo.git -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊基础理论部分/钱包系列/账户抽象化.md: -------------------------------------------------------------------------------- 1 | https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020 -------------------------------------------------------------------------------- /Learning_Roadmaps_And_Resources/死磕区块链_中阶学习路线图.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Learning_Roadmaps_And_Resources/死磕区块链_中阶学习路线图.xmind -------------------------------------------------------------------------------- /Learning_Roadmaps_And_Resources/死磕区块链_初阶学习路线图.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Learning_Roadmaps_And_Resources/死磕区块链_初阶学习路线图.xmind -------------------------------------------------------------------------------- /Learning_Roadmaps_And_Resources/死磕区块链_高阶学习路线图.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Learning_Roadmaps_And_Resources/死磕区块链_高阶学习路线图.xmind -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊基础理论部分/2.以太坊相关术语.md: -------------------------------------------------------------------------------- 1 | > 文章以及资料（开源）：[github地址](https://github.com/mindcarver/blockchain_guide) 2 | 3 | [TOC] 4 | 5 | -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/设计模式/可维护性/contract_relay.md: -------------------------------------------------------------------------------- 1 | https://github.com/NoharaHiroshi/upgradability-solidity-demo.git 2 | 3 | 4 | 5 | https://github.com/33357/smartcontract-apps.git -------------------------------------------------------------------------------- /DApp_Development/安全审计/合约漏洞/算法上下溢出.md: -------------------------------------------------------------------------------- 1 | https://zhuanlan.zhihu.com/p/105471579 2 | 3 | 用openzepplin的库safemath库 4 | 5 | 尽可能使用高版本的solidity . 0.4 的版本有溢出问题，0.8的solidity版本已经解决了 6 | 7 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/BLS签名算法.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | ## 参考 10 | 11 | [1] ： [bls-go实现](https://github.com/chuwt/chia-bls-go) 12 | 13 | -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/ton/ton开发/ton开发.md: -------------------------------------------------------------------------------- 1 | ## js库 2 | 3 | ```console 4 | @orbs-network/ton-access rpc提供商类似infra 5 | @ton/ton @ton/crypto @ton/core API调用Ton 6 | ``` -------------------------------------------------------------------------------- /DApp_Development/安全审计/合约漏洞/权限控制漏洞.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | ## 参考 8 | 9 | https://learnblockchain.cn/article/4726 10 | 11 | 12 | 13 | https://learnblockchain.cn/article/1438 -------------------------------------------------------------------------------- /Public_Chain_Development/Consensus_Mechanisms/Aardvark协议（BFT）.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Consensus_Mechanisms/Aardvark协议（BFT）.pdf -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/交易缓冲池.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/交易缓冲池.xmind -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊关键函数全景图（持续更新）.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊关键函数全景图（持续更新）.xmind -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/downloader.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/downloader.xmind -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/P2P广播和同步.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/P2P广播和同步.xmind -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p代码概览.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p代码概览.xmind -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p源码分析.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p源码分析.xmind -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/新区块传播源码.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/新区块传播源码.xmind -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/设计模式/可维护性/contract_regestry.md: -------------------------------------------------------------------------------- 1 | https://research.csiro.au/blockchainpatterns/general-patterns/contract-structural-patterns/contract-registry/ 2 | 3 | https://github.com/NoharaHiroshi/upgradability-solidity-demo.git -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/设计模式/安全/mutex.md: -------------------------------------------------------------------------------- 1 | 禁止递归 2 | 3 | https://github.com/maxwoe/solidity_patterns.git 4 | 5 | https://github.com/NoharaHiroshi/upgradability-solidity-demo.git 6 | 7 | https://github.com/33357/smartcontract-apps.git 8 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/batch-submitter.md: -------------------------------------------------------------------------------- 1 | > 定期从L2区块中将交易数据以打包的形式组装到交易 2 | 3 | - 打包批量交易 `txBatch` 提交到 L1 的 `CTC` 合约； 4 | - 打包批量状态 `stateBatch` 提交到 L1 的`StateCommitmentChain.sol` 5 | - 之后这些交易进入`等待挑战`窗口，挑战方式就是`欺诈证明`； -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p模块 2 2 2.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p模块 2 2 2.xmind -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p网络 2 2 2.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p网络 2 2 2.xmind -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p服务启动 2 2 2.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p服务启动 2 2 2.xmind -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p节点通信 2 2 2.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p节点通信 2 2 2.xmind -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/发起TCP连接 2 2 2.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/发起TCP连接 2 2 2.xmind -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p网络RLPX传输协议 2 2 2.xmind: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/blockchainGuide/blockchainguide/HEAD/Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/p2p/p2p网络RLPX传输协议 2 2 2.xmind -------------------------------------------------------------------------------- /DApp_Development/solidity-tech.md: -------------------------------------------------------------------------------- 1 | ## 合约基础 2 | 3 | ### solidity 4 | #### solidity 推荐写法 5 | #### solidity 常见bug 6 | 7 | 8 | ## 常用框架 9 | ### truffle 10 | ### web3.js 11 | ### hardhat 12 | 13 | ## 合约测试 14 | 15 | ## 合约安全 16 | 17 | ## 合约案例 18 | 19 | ## 合约安全审计 20 | -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/cosmos/ibc/interchain-accounts.md: -------------------------------------------------------------------------------- 1 | https://medium.com/chainapsis/why-interchain-accounts-change-everything-for-cosmos-interoperability-59c19032bf11 2 | 3 | 4 | 5 | demo 6 | 7 | https://github.com/cosmos/interchain-accounts-demo -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊基础理论部分/深入理解verkle tree.md: -------------------------------------------------------------------------------- 1 | 1. https://zhuanlan.zhihu.com/p/500860920https://link.zhihu.com/?target=https%3A//math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf) 2 | 2. https://learnblockchain.cn/article/2684 -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/设计模式/安全/Rate Limit.md: -------------------------------------------------------------------------------- 1 | https://consensys.github.io/smart-contract-best-practices/development-recommendations/precautions/rate-limiting/ 2 | 3 | https://github.com/maxwoe/solidity_patterns.git 4 | 5 | https://github.com/NoharaHiroshi/upgradability-solidity-demo.git -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊基础理论部分/无状态以太坊.md: -------------------------------------------------------------------------------- 1 | https://mirror.xyz/web3nomad.eth/yCmv1JOPNE0_F7joZU08oKBIDfM62Cqji6ZVYDVjdtQ 2 | 3 | https://cloud.tencent.com/developer/article/1186332 4 | 5 | https://blog.ethereum.org/2020/01/28/eth1x-files-the-stateless-ethereum-tech-tree -------------------------------------------------------------------------------- /DApp_Development/eip/EIP1559详解.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | ## 参考 18 | 19 | [1] : [eip1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md) 20 | 21 | [2] : [ethpricing search](https://ethresear.ch/t/draft-position-paper-on-resource-pricing/2838) -------------------------------------------------------------------------------- /Layer2_Solutions/btclayer2/btclayer2社区资料汇总.md: -------------------------------------------------------------------------------- 1 | - https://bitvm.org/ 2 | - https://linktr.ee/roos_btcl2 roos 参考 3 | - bob. https://github.com/bob-collective/bob参考 4 | - https://github.com/orgs/Tunachain/repositories (重点) 5 | - https://zksats.io/bridge (利用polygon的zk 方案) 6 | - https://bvm.network/ (重中之重) 7 | - https://github.com/l2labs （） 8 | 9 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/layer2资料.md: -------------------------------------------------------------------------------- 1 | http://layer2.wenwoha.com 2 | 3 | [数据可用性的理解](https://coinmarketcap.com/alexandria/article/what-is-data-availability) 4 | 5 | [数据可用性的理解概要](https://twitter.com/sanjaypshah/status/1580221120405327872) 6 | 7 | [以太坊 Rollup 与 Celestia 上的主权 Rollup 之间的权衡](https://twitter.com/sanjaypshah/status/1575188529361014784) -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/死磕以太坊源码分析之trie-15.md: -------------------------------------------------------------------------------- 1 | > 死磕以太坊源码分析之Trie树 2 | > 3 | > 配合以下代码进行阅读：https://github.com/blockchainGuide/ 4 | > 5 | > 希望读者在阅读过程中发现问题可以及时评论哦，大家一起进步。 6 | 7 | 8 | 9 | 10 | 11 | ## 参考 12 | 13 | > https://mindcarver.cn 14 | > 15 | > https://github.com/blockchainGuide 16 | 17 | -------------------------------------------------------------------------------- /DApp_Development/合约基础/solidity_fallback和receive.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | ## 参考 8 | 9 | https://docs.soliditylang.org/en/v0.6.7/060-breaking-changes.html#semantic-and-syntactic-changes 10 | 11 | https://mirror.xyz/ninjak.eth/EroVZqHW1lfJFai3umiu4tb9r1ZbDVPOYC-puaZklAw 12 | 13 | https://blog.csdn.net/weixin_45719444/article/details/121161842 -------------------------------------------------------------------------------- /TODO.md: -------------------------------------------------------------------------------- 1 | - [ ] BLS12-381 2 | - [ ] eip1559 3 | - [ ] 账户抽象话EIP-4337（最新草案） 4 | - 多签安全 5 | - 智能合约钱包VSMPC钱包 6 | - 基于社交与时间的钱包恢复 7 | - 地址黑白名单 8 | - 无需g a s费用的元交易和批量交易 9 | - Gnosis Safe多签 10 | - [ ] 自定义EVM指令实现业务逻辑 11 | - [ ] Libp2p 12 | 13 | 14 | 15 | ## 密码学 16 | 17 | - [ ] Schnorr签名 18 | - [ ] [VDF](https://vdfresearch.org/) 19 | 20 | 21 | -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/设计模式/可维护性/数据逻辑分离.md: -------------------------------------------------------------------------------- 1 | https://developer.aliyun.com/article/617127 2 | 3 | https://www.cnblogs.com/Lands-ljk/p/12213543.html 4 | 5 | https://www.geekmeta.com/article/1306640.html 6 | 7 | https://ethereum.org/zh/developers/tutorials/smart-contract-security-guidelines/ 8 | 9 | https://github.com/NoharaHiroshi/upgradability-solidity-demo.git -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/整体理解.md: -------------------------------------------------------------------------------- 1 | # 组件 2 | 3 | ## op-batcher 4 | 5 | - 将交易压缩成batchs 6 | - 将batches发布到L1确保可用性和完整性 7 | 8 | ## op-geth 9 | 10 | - 修改并存储状态 11 | - 处理交易，更改状态 12 | 13 | ## op-proposer 14 | 15 | State root commitments 由op-proposer 提出到L1上的L2outputOracle合约， 这个提案不会立即生效，需要经过挑战期 16 | 17 | https://stack.optimism.io/docs/build/ -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/tendermint/死磕tendermint源码分析_1.md: -------------------------------------------------------------------------------- 1 | > Tendermint core 2 | 3 | > https://learnblockchain.cn/article/372 4 | > 5 | > https://learnblockchain.cn/article/1553 6 | > 7 | > https://learnblockchain.cn/article/1151 (重点) 8 | > 9 | > https://learnblockchain.cn/2019/06/15/68fb29cd00de 10 | > 11 | > https://github.com/wupeaking/tendermint_code_analysis -------------------------------------------------------------------------------- /Public_Chain_Development/Consensus_Mechanisms/BFT 协议整体看法.md: -------------------------------------------------------------------------------- 1 | # 基于协约 2 | 3 | ## PBFT 4 | 5 | ## chain协议 6 | 7 | ## ring协议 8 | 9 | ## BFT-Smart协议 10 | 11 | > https://www.cnblogs.com/Evsward/p/bft-smart.html 12 | > 13 | > https://zhuanlan.zhihu.com/p/101270841 14 | 15 | ## Zyzzyva 16 | 17 | > http://sosp2007.org/papers/sosp052-kotla.pdf 18 | > 19 | > https://www.jianshu.com/p/b4674d3f7ebd -------------------------------------------------------------------------------- /Privacy_Computing/安全多方计算/门限签名方案TSS.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## 大致理解 4 | 首先每个人各自生成自己的私钥片段uᵢ并秘密地保存起来，假设是2-of-3方案，那么缺少一方也可以恢复完整私钥 5 | 6 | ## 门限密钥生成 7 | 去中心化的为每个参与者生成私钥碎片 8 | 9 | ## 门限签名 10 | 私钥碎片签名出签名碎片，然后可以拼接成完整私钥的完整签名 11 | 12 | 13 | 14 | ## 参考 15 | [门限签名](https://medium.com/@asteacherluo/%E4%B8%87%E5%AD%97%E9%95%BF%E6%96%87%E9%9B%B6%E5%9F%BA%E7%A1%80%E7%A7%91%E6%99%AE%E9%97%A8%E9%99%90%E7%AD%BE%E5%90%8D-a0a7bc48eee2) 16 | -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/死磕以太坊源码分析之EVM介绍-18.md: -------------------------------------------------------------------------------- 1 | > 死磕以太坊源码分析之EVM介绍 2 | > 3 | > 配合以下代码进行阅读：https://github.com/blockchainGuide/ 4 | > 5 | > 写文不易，给个小关注，有什么问题可以指出，便于大家交流学习。 6 | > 7 | 8 | ## 目录结构 9 | 10 | > |-opcodes.go 具体指令集的含义 11 | 12 | 13 | 14 | 15 | 16 | ## 参考 17 | 18 | > https://mindcarver.cn 19 | > 20 | > https://github.com/blockchainGuide 21 | > 22 | 23 | 24 | 25 | -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/cosmos/cometBFT/死磕cometBFT共识源码.md: -------------------------------------------------------------------------------- 1 | ![共识](http://yangzhe.me/pic/tenderminnt-bft/summary.png) 2 | 3 | 4 | ![共识](http://yangzhe.me/pic/tenderminnt-bft/timeout.png) 5 | 6 | ------ 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/Polygon zkevm/QA和资料.md: -------------------------------------------------------------------------------- 1 | - 多签合约 2 | 3 | 4 | 5 | 6 | 7 | # 资料 8 | 9 | https://github.com/0xPolygonHermez/zkevm-techdocs/tree/a6d46da98ad32ace544e5dbc31d34831f9cc1bdd 10 | 11 | 12 | 13 | 14 | 15 | https://www.reddit.com/api/v1/authorize?client_id=oCSL0QBV5BAn5SGf9r3PTw&response_type=code&%20state=randomstring&redirect_uri=https://test1.erbie.io/oauth2&duration=permanent&scope=identity%20read%20submit%20vote -------------------------------------------------------------------------------- /DApp_Development/安全审计/合约漏洞/短地址参数攻击.md: -------------------------------------------------------------------------------- 1 | 短地址攻击是利用EVM在参数长度不够时自动在右方补0的特性，通过去除钱包地址末位的0，达到将转账金额左移放大的效果。目前主要依靠客户端主动检查地址长度来避免该问题，另外web3层面也增加了参数格式校验。虽然EVM层仍然可以复现，但是在实际应用场景中基本没有问题。 2 | 3 | 4 | 5 | 6 | 7 | ## 参考 8 | 9 | https://www.anquanke.com/post/id/214757 10 | 11 | 12 | 13 | https://zhuanlan.zhihu.com/p/34470071 14 | 15 | https://ethbook.abyteahead.com/ch10/shortattack.html 16 | 17 | https://www.freebuf.com/articles/blockchain-articles/199903.html -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/op-technology-stack.md: -------------------------------------------------------------------------------- 1 | ## 通道帧 2 | 3 | 将多笔交易以及对应的state root 当做一帧 ，从而可以只提交state root ，减少网络消耗和gas 消耗。 4 | 5 | ## 通过查分编码实现流压缩 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | ## 个人想法 16 | 17 | 想以消费链的形式来做共识层(实际通过cosmos 来做共识层)，但是执行层依赖op-geth /或者evm 兼容链, 18 | 19 | ![aa](https://community.optimism.io/assets/img/overall-process.4d7af557.svg) 20 | 21 | ![bb](https://community.optimism.io/assets/img/overall-process.9af6f67d.svg) -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/安全多方计算/同态加密vs多方安全计算协议.md: -------------------------------------------------------------------------------- 1 | 同态加密协议和多方安全计算协议都是隐私保护相关的协议，但是它们的实现方式和解决问题的方式不同。 2 | 3 | 同态加密协议的主要目的是允许对加密的数据进行计算，而无需解密它们。因此，同态加密协议通常用于数据隐私保护，例如在云计算中。同态加密协议的基本思想是对数据进行加密，使得密文上的操作结果与明文上的结果相同。同态加密协议可以分为完全同态加密和部分同态加密两种类型。 4 | 5 | 多方安全计算协议的主要目的是允许多个参与者共同计算一个函数，而不暴露彼此的私密输入。多方安全计算协议可以分为基于加密的协议和基于非加密的协议两种类型。基于加密的多方安全计算协议通常使用同态加密技术实现，但是其目的是在保护隐私的同时允许多个参与者进行计算。基于非加密的多方安全计算协议通常使用秘密共享技术来保护隐私，并且可以在不知道其他参与者私密输入的情况下进行计算。 6 | 7 | 因此，同态加密协议和多方安全计算协议都是隐私保护相关的协议，但是它们的实现方式和目的不同。 -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/Polygon zkevm/polygon zk evm 概述 .md: -------------------------------------------------------------------------------- 1 | 1. zknode 2 | 2. zk bridge 3 | 3. zk prover 4 | 4. 为什么设计一个交易一个区块 5 | 5. 6 | 7 | 8 | 9 | ## 架构 10 | 11 | ![架构](https://zkevm.polygon.technology/assets/images/fig1-simpl-arch-96aab58adcddbfb470aa79f743bc4666.png) 12 | 13 | - onsensus Contract (PolygonZkEVM.sol) 14 | - zkNode 15 | - Synchronizer 16 | - Sequencers & Aggregators 17 | - RPC 18 | - zkProver 19 | - zkEVM Bridge 20 | 21 | ----- 22 | 23 | 24 | 25 | 26 | 27 | -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/设计模式/安全/安全转账.md: -------------------------------------------------------------------------------- 1 | https://codeantenna.com/a/CFr6RnHdQr 2 | 3 | https://dreamerjonson.com/2018/11/20/solidity-25-thansfer2/index.html 4 | 5 | https://learnblockchain.cn/article/2191 6 | 7 | https://blog.csdn.net/m0_37714470/article/details/119113895 8 | 9 | https://robinchen95.com/documents/Refer/36-智能合约安全综述.pdf 10 | 11 | https://github.com/maxwoe/solidity_patterns.git 12 | 13 | https://github.com/NoharaHiroshi/upgradability-solidity-demo.git 14 | 15 | https://github.com/33357/smartcontract-apps.git -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/设计模式/solidity 之设计模式.md: -------------------------------------------------------------------------------- 1 | https://blog.csdn.net/Tesla_Zhou/article/details/111743243 2 | 3 | https://www.yisu.com/zixun/515955.html 4 | 5 | http://ww2.inf.ufg.br/~insight/blockarch2021/ICSA_talk.pdf 6 | 7 | 8 | 9 | https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/articles/3_features/35_contract/solidity_design_patterns.html 10 | 11 | https://blog.logrocket.com/developers-guide-solidity-design-patterns/?ref=morioh.com&utm_source=morioh.com 12 | 13 | https://github.com/maxwoe/solidity_patterns.git -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊源码分析/死磕以太坊源码分析之EthDB-17.md: -------------------------------------------------------------------------------- 1 | > 死磕以太坊源码分析之EthDB 2 | > 3 | > 配合以下代码进行阅读：https://github.com/blockchainGuide/ 4 | > 5 | > 写文不易，给个小关注，有什么问题可以指出，便于大家交流学习。 6 | 7 | 8 | 9 | ## 目录结构 10 | 11 | ``` 12 | |-leveldb.go 13 | |-memorydb.go 14 | |-batch.go 15 | |-database.go 16 | ``` 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | ## 参考 25 | 26 | > https://mindcarver.cn 27 | > 28 | > https://github.com/blockchainGuide 29 | > 30 | > https://www.jianshu.com/nb/9496943 （levelDB源码） 31 | 32 | 33 | 34 | -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕libp2p之DCUtR.md: -------------------------------------------------------------------------------- 1 | 中继是用作代理以遍历NAT的，但是这种方法扩展和维护成本高，可能会导致低带宽、高延迟的连接。打洞是另一种技术，它使在NAT后面的两个节点能够直接通信。然而，除了中继节点之外，它还需要另一种基础设施，称为信令服务器。 2 | 3 | 信令服务器是指用于在P2P网络中促进节点之间通信的服务器或服务，具体而言是用于建立、维护和终止两个在NAT后面的节点之间的直接通信通道的。它有助于发现节点的外部IP地址和端口，并通过在节点之间中继消息来遍历NAT。 4 | 5 | 好消息是，libp2p提供了一个打洞解决方案，消除了集中式的信令服务器的需求，并允许使用分布式中继节点。 6 | 7 | ## 什么是通过中继进行直接连接升级 8 | 9 | libp2p DCUtR（通过中继进行直接连接升级）是一种协议，用于通过打洞建立节点之间的直接连接，无需信令服务器。DCUtR涉及到同步和打开连接到每个节点的预测外部地址。 10 | 11 | DCUtR协议使用协议ID /libp2p/dcutr，并涉及连接和同步消息的交换。 12 | 13 | DCUtR协议支持不同类型的连接，如TCP和QUIC，建立连接的过程对于每种类型都是不同的。 -------------------------------------------------------------------------------- /Public_Chain_Development/数据可用性DA探索/数据可用性DA探索.md: -------------------------------------------------------------------------------- 1 | https://www.8btc.com/article/6721900 2 | 3 | https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698 4 | 5 | https://polynya.medium.com/volitions-best-of-all-worlds-cfd313aec9a8 6 | 7 | ### 数据可用性的通用解决方案 8 | 9 | https://www.aicoin.com/article/321400.html 10 | 11 | https://wiki.polygon.technology/docs/avail/introduction/what-is-avail/ 12 | 13 | https://eips.ethereum.org/EIPS/eip-4844 14 | 15 | https://www.aicoin.com/article/321400.html 16 | 17 | 18 | 19 | :Celestia -https://www.defidaonews.com/article/6743554 -------------------------------------------------------------------------------- /DApp_Development/合约高级技巧/死磕solidity之内存布局.md: -------------------------------------------------------------------------------- 1 | https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjnhsehuY77AhVTSmwGHaP-AB4QFnoECCIQAw&url=https%3A%2F%2Fmirror.xyz%2Fxyyme.eth%2F5eu3_7f7275rqY-fNMUP5BKS8izV9Tshmv8Z5H9bsec&usg=AOvVaw1gUoxZKv9GACaod5CpJweh 2 | 3 | 4 | 5 | https://learnblockchain.cn/docs/solidity/internals/layout_in_memory.html 6 | 7 | 8 | 9 | https://coinsbench.com/solidity-layout-and-access-of-storage-variables-simply-explained-1ce964d7c738 10 | 11 | https://cloud.tencent.com/developer/article/1975388 12 | 13 | 包括 14 | 15 | calldata的布局 16 | 17 | 内存变量的布局 18 | 19 | 状态变量的存储模型 20 | 21 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/ovm操作.md: -------------------------------------------------------------------------------- 1 | 在我们有了沙箱 OVM，我们需要将智能合约编译为 OVM 字节码。以下是我们的一些选择： 2 | 3 | - 创建一种可编译为 OVM 的新智能合约语言：一种新的智能合约语言是一个很容易被忽略的想法，因为它需要从头开始重新做所有事情，我们已经同意我们不会在这里这样做。 4 | - 将 EVM 字节码转译为 OVM 字节码：曾[尝试过](https://github.com/ethereum-optimism/optimism-monorepo/blob/2ca62fb41be6ef69b0c07a1bd5502ac425aaf341/packages/solc-transpiler/src/compiler.ts#L420-L496)但由于复杂性而放弃。 5 | - 通过修改编译器以生成 OVM 字节码来支持 Solidity 和 Vyper。 6 | 7 | 8 | 9 | 10 | 11 | > https://research.paradigm.xyz/optimism 12 | 13 | https://github.com/ethereum-optimism/solidity/blob/df005f39493525b43f1153dff8da5910a2b83e34/libsolidity/codegen/CompilerContext.cpp#L64-L367 -------------------------------------------------------------------------------- /DApp_Development/安全审计/安全相关资料.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjc_eqbipH7AhWy1TgGHUFlDMEQFnoECAsQAQ&url=https%3A%2F%2Fpaper.seebug.org%2F632%2F&usg=AOvVaw14eo8RAc762vHREfHWyWtU 4 | 5 | https://mirror.xyz/ninjak.eth/ygaDE0QQwn3lfI-AVaw0ZMqHQtWCdzo-XV450j2camc 6 | 7 | https://paper.seebug.org/632/ 8 | 9 | https://ethernaut.zeppelin.solutions/level/0xf70706db003e94cfe4b5e27ffd891d5c81b39488 （合约漏洞合集网站） 10 | 11 | 12 | 13 | https://consensys.github.io/smart-contract-best-practices/development-recommendations/general/external-calls/#favor-pull-over-push-for-external-calls openzepplin安全开发建议 14 | 15 | -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/ton/资料.md: -------------------------------------------------------------------------------- 1 | - [ton 官方文档](https://docs.ton.org/mandarin/) 2 | - [ton-awesome](https://github.com/ton-community/awesome-ton) 3 | - [ton英文课程详细](https://stepik.org/course/176754/) 4 | - [合约开发工具](https://github.com/ton-org/blueprint) 5 | - [ton testnet explorer](https://testnet.tonscan.org/) 6 | - [ton-cli](https://github.com/disintar/toncli) 7 | - [ton 课程](https://github.com/romanovichim/TonFunClessons_Eng) 8 | - [详细讲解合约](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/lessons/pipeline/chatbot.md) 9 | 10 | 11 | 12 | # ton 链 13 | 14 | 15 | 16 | ## Tact 17 | 18 | 19 | 20 | ## Func 21 | 22 | 23 | 24 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/celestia/celestia简介.md: -------------------------------------------------------------------------------- 1 | ## 介绍 2 | 3 | Celestia is a data availability (DA) layer that provides a scalable solution to the [data availability problem](https://coinmarketcap.com/alexandria/article/what-is-data-availability). 4 | 5 | ## 关键功能 6 | 7 | ### [data availability sampling](https://blog.celestia.org/celestia-mvp-release-data-availability-sampling-light-clients) (DAS) 8 | 9 | Celestia使用二维Reed-Solomon编码方案对块数据进行编码：将每个块数据拆分为k×k个块，排列在k×k矩阵中，并通过多次Reed-Solmon编码将奇偶校验数据扩展为2k×2k扩展矩阵 10 | 11 | 然后，为扩展矩阵的行和列计算4k个单独的Merkle根；这些Merkle根的Merkle根部被用作块报头中的块数据承诺。 12 | 13 | ### [Namespaced Merkle trees](https://github.com/celestiaorg/nmt) (NMTs). 14 | 15 | 16 | 17 | ## QA 18 | 19 | -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕p2p网络之relay协议.md: -------------------------------------------------------------------------------- 1 | > 当一个对等端无法监听公共地址时，它可以拨出到中继对等端，这将保持长期连接打开。其他对等方将能够使用p2p电路地址通过中继对等方拨号，从而将流量转发到其目的地。 2 | > 3 | > 中继连接是端到端加密的，这意味着充当中继的对等方无法读取或篡改流经连接的任何流量 4 | 5 | 6 | 7 | ## 应用场景 8 | 9 | 假设我有一个对等ID为QmAlice的对等。我想把我的地址给我的朋友QmBob，但我有一个NAT，它不允许任何人直接给我打电话。 10 | 11 | ![image-20221018142037486](https://tva1.sinaimg.cn/large/008vxvgGgy1h79f7koq8qj30z90u0mzn.jpg) 12 | 13 | 节点A位于NAT和/或防火墙后面，例如通过AutoNAT服务检测到的。 14 | 15 | 因此，节点A请求与中继R进行预约，即节点A请求中继R代表其侦听传入连接。 16 | 17 | 节点B希望与节点a建立连接。鉴于节点**a不公布任何直接地址**，而只公布中继地址，节点B连接到中继R，要求中继R中继到a的连接。 18 | 19 | 中继R将连接请求转发到节点A，并最终中继A和B发送的所有数据。 20 | 21 | 22 | 23 | ## 参考 24 | 25 | https://github.com/libp2p/specs/blob/master/relay/circuit-v2.md -------------------------------------------------------------------------------- /Decentralized_Storage/IPFS/IPFS学习点.md: -------------------------------------------------------------------------------- 1 | > 1. DAG 2 | > 2. https://github.com/xipfs/IPFS-Internals （源码分析） 3 | > 3. IPLD组件 4 | 5 | 6 | 7 | > geth --datadir data --nodiscover --istanbul.blockperiod 5 --syncmode full --mine --minerthreads 1 --verbosity 5 --networkid 10 --rpc --rpcaddr 127.0.0.1 --rpcport 22002 --rpcapi admin,db,eth,debug,miner,net,shh,txpool,personal,web3,quorum,istanbul --emitcheckpoints --port 30302 8 | 9 | 10 | 11 | > PRIVATE_CONFIG="ignore geth --datadir data --nodiscover --istanbul.blockperiod 5 --syncmode full --mine --minerthreads 1 --verbosity 5 --networkid 10 --rpc --rpcaddr 127.0.0.1 --rpcport 22000 --rpcapi admin,db,eth,debug,miner,net,shh,txpool,personal,web3,quorum,istanbul --emitcheckpoints --port 30300" -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/cosmos/ibc/ibc原理.md: -------------------------------------------------------------------------------- 1 | ![image-20230409083925782](https://p.ipic.vip/tkc2td.png) 2 | 3 | 4 | 5 | ## ibc协议核心 6 | 7 | https://ibcprotocol.dev/protocol/ 8 | 9 | https://ibc.cosmos.network/main/ibc/overview.html 10 | 11 | 12 | 13 | ## ibc 轻客户端端 14 | 15 | https://github.com/tendermint/tendermint 16 | 17 | ## ibc app 18 | 19 | https://github.com/cosmos/ibc/pull/615/files 20 | 21 | https://ibcprotocol.dev/applications/ 22 | 23 | 24 | 25 | ## ibc doc 26 | 27 | https://ibcprotocol.dev/documentation 28 | 29 | 30 | 31 | ## zk&modular-IBC 32 | 33 | 针对异构链,并且和celestia合作 34 | 35 | https://polymerlabs.medium.com/blockchain-bridges-101-a-guide-to-inter-blockchain-communication-ibc-3efc092770b1 -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism spec分析/op-批量提交.md: -------------------------------------------------------------------------------- 1 | # 批量提交者 2 | 3 | 批次提交者，也称为批处理者，是将 L2 排序器数据提交到 L1 的实体，以使其可供验证者使用。 4 | 5 | 数据事务的格式在[派生规范](https://github.com/ethereum-optimism/optimism/blob/develop/specs/derivation.md)中定义：数据以与从数据派生到 L2 块相反的顺序从 L2 块构造。 6 | 7 | 时间、操作和交易签名是特定于实现的：任何数据都可以随时提交，但从验证者的角度来看，只有符合[派生规范规则的数据才是有效的。](https://github.com/ethereum-optimism/optimism/blob/develop/specs/derivation.md) 8 | 9 | 最小的批处理程序实现可以定义为以下操作的循环： 10 | 11 | 1. 查看`unsafe`L2区块号是否超过`safe`区块号：`unsafe`需要提交数据。 12 | 2. 迭代所有不安全的 L2 块，跳过之前提交的任何块。 13 | 3. [打开一个通道，缓冲所有要提交的 L2 块数据，同时应用派生规范](https://github.com/ethereum-optimism/optimism/blob/develop/specs/derivation.md)中定义的编码和压缩。 14 | 4. 从通道中拉出帧来填充数据事务，直到通道为空。 15 | 5. 将数据交易提交到L1 16 | 17 | 安全/不安全的 L2 视图不会在数据提交后立即更新，也不会在 L1 上确认时立即更新，因此可能需要特别注意不要重复数据提交。 -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/op-node/op-node.md: -------------------------------------------------------------------------------- 1 | ## driver-sequencer 2 | 3 | sequencer 在完成构建L2区块的过程中，会调用engine, 会调用L1客户端获取所有指定L1 block （L2 Epoch，长达12秒，但是L2block 2秒一个，所以一个L1 大概出6个L2区块）的收据，从中获取depositTx的收据， 4 | 5 | L2 block的第一笔交易必须是depositTxType,且必须存在一笔 L1 info deposit tx （这是一笔关于L1 block Info的交易，他是把block的信息放到了tx.data里了，按照DepositTx 格式，） 6 | 7 | 关于L2的系统配置，他是先在L1的合约上进行了设置，并触发了事件，然后sequencer通过扫描L1区块里面的交易事件，从而将配置导入到rollup node中。 8 | 9 | 实际PreparePayloadAttributes 就是从L1 获取上面的L1 block info 和L1上质押合约里的交易，两种都会转换成deposit tx,最终当作palayload 的属性。 10 | 11 | forkchoiceUpdated 会调用op-geth 的方法，最终走到了buildPayload， 并没有进行共识 ，实际都是走的那个prepare-fianliazeandassemble流程， 但是这个区块有被保存吗，状态信息呢 12 | 13 | opnode 将状态转换完毕后，就该op-batcher干事了 14 | 15 | 16 | 17 | ## QA 18 | 19 | 1. 根据测试代码，还是不太能理解漂移窗口 ，如何查找l1origin -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/椭圆曲线/椭圆曲线学习路线.md: -------------------------------------------------------------------------------- 1 | - [x] : 2 | 3 | 椭圆曲线密码学（ECC）是现代密码学中的重要领域，广泛应用于加密、签名和密钥交换等场景。要深入学习椭圆曲线密码学，您需要学习多个方面的知识，包括数学、密码学原理和实际应用。以下是一个学习路径，帮助您系统地掌握椭圆曲线密码学： 4 | 5 | 1. **数论基础**：数论是密码学的基础，特别是椭圆曲线密码学。学习模运算、同余、费马小定理、欧拉定理等基本数论概念。 6 | 2. **代数基础**：学习有限域、群、环、域等代数结构，了解它们在密码学中的作用。 7 | 3. **椭圆曲线基础**：学习椭圆曲线的数学定义、椭圆曲线上的点加法运算、椭圆曲线的性质和分类（如Weierstrass曲线、Edwards曲线等）。 8 | 4. **椭圆曲线上的离散对数问题**：了解离散对数问题在椭圆曲线上的变种，以及为什么它在椭圆曲线上比在其他场景下更难解决。 9 | 5. **椭圆曲线密码学基本原理**：学习椭圆曲线密码学中的基本原理和算法，如椭圆曲线 Diffie-Hellman（ECDH）密钥交换、椭圆曲线数字签名算法（ECDSA）等。 10 | 6. **椭圆曲线密码学的实现与优化**：学习如何实现椭圆曲线密码学算法，以及针对不同场景的优化技巧，如点压缩、快速加法算法等。 11 | 7. **安全性和攻击**：了解椭圆曲线密码学中的潜在安全隐患和攻击手段，如侧信道攻击、时序攻击等，以及如何防范这些攻击。 12 | 8. **椭圆曲线选择与标准**：了解如何选择合适的椭圆曲线参数，以及相关的标准和推荐曲线（如NIST推荐曲线、Curve25519等）。 13 | 9. **后量子密码学与椭圆曲线密码学**：了解量子计算对椭圆曲线密码学的潜在威胁，以及密码学界为抵抗量子攻击而提出的替代方案 14 | 15 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/安全多方计算/混淆电路框架.md: -------------------------------------------------------------------------------- 1 | 混淆电路（oblivious circuit）是一种安全计算技术，可以将输入数据保持私密，并在不泄露私密信息的同时，计算出函数的结果。混淆电路框架是一种通用的实现混淆电路的方式，它可以将任何电路转化为混淆电路，使得输出结果不依赖于输入数据，并且输入数据保持私密。 2 | 3 | 混淆电路框架的基本思想是，将一个电路分解成多个组件，每个组件的输入和输出都是明文，但组件之间的连接和计算过程都是加密的。这样，每个组件只知道自己的输入和输出，而对其他组件的输入和输出一无所知，从而实现了保护隐私的目的。 4 | 5 | 具体来说，混淆电路框架分为两个阶段：编码阶段和执行阶段。 6 | 7 | 在编码阶段，将要计算的电路转化为一个混淆电路，并将其分解成多个组件。每个组件都由两个函数组成：加密函数和解密函数。加密函数用于将明文输入加密成密文，解密函数用于将密文输出解密成明文。组件之间的连接和计算过程都是加密的，因此每个组件只知道自己的输入和输出，而对其他组件的输入和输出一无所知。 8 | 9 | 在执行阶段，每个输入方将输入数据通过加密函数加密成密文，然后将密文输入到混淆电路中，由执行阶段的参与者进行计算，并输出密文结果。最后，每个输出方将输出的密文通过解密函数解密成明文，得到计算结果。 10 | 11 | 混淆电路框架的关键问题是如何设计加密和解密函数，使得组件之间的计算过程和连接都是保密的。一种常用的做法是使用同态加密技术，将加密函数和解密函数都设计为同态加密算法，从而实现组件之间的保密计算。另外，混淆电路框架还需要考虑性能和可扩展性等问题，以便在实际应用中能够实现高效的计算和处理。 12 | 13 | 总的来说，混淆电路框架是一种重要的安全计算技术，可以在保护隐私的同时，实现计算结果的安全计算和传输。在实际应用中，混淆电路框架被广泛应用于保护隐私和实现数据安全计算，如隐私保护数据挖掘、机器学习、数据共享等领域。 -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/libp2p源码分析/死磕libp2p之DHT路由.md: -------------------------------------------------------------------------------- 1 | ## 接口定义 2 | 3 | ```go 4 | //ContentRouting是间接寻址的值提供程序层。它用于查找有关谁拥有什么内容的信息。 5 | //内容由CID（内容标识符）标识，CID对哈希进行编码 6 | //以防将来使用。 7 | ``` 8 | 9 | ```go 10 | type ContentRouting interface { 11 | // 将给定的cid添加到内容路由系统 12 | Provide(context.Context, cid.Cid, bool) error 13 | 14 | // 搜索能够提供给定key的peers 15 | FindProvidersAsync(context.Context, cid.Cid, int) <-chan peer.AddrInfo 16 | } 17 | ``` 18 | 19 | 20 | 21 | ```go 22 | type PeerRouting interface { 23 | // 搜索具有给定ID的peer，并返回相关地址信息 24 | FindPeer(context.Context, peer.ID) (peer.AddrInfo, error) 25 | } 26 | ``` 27 | 28 | 29 | 30 | ```go 31 | type Routing interface { 32 | ContentRouting // 内容路由 33 | PeerRouting // 节点路由 34 | ValueStore // 基础存取接口 35 | Bootstrap(context.Context) error // // 允许caller提示路由系统进入Boostrapped状态并保持在那里。它不是同步调用。 36 | } 37 | ``` 38 | 39 | ```go 40 | type PubKeyFetcher interface { 41 | // GetPublicKey returns the public key for the given peer. 42 | GetPublicKey(context.Context, peer.ID) (ci.PubKey, error) 43 | } 44 | ``` 45 | 46 | 47 | 48 | -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕libp2p网络之multiAddress.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## 概念 4 | 5 | libp2p区分了peer 的身份和位置。peer 的身份是稳定的、可验证的，并且在对等方的整个生命周期内有效， peer 身份源于对等id规范中描述的公钥。 6 | 7 | 在特定的网络上，在特定的时间点，peer可能有一个或多个位置，可以使用地址表示。例如，可以通过TCP端口1234上7.7.7.7的全局IPv4地址访问. 8 | 9 | Libp2p 是不受传输限制的，不单单是只支持tcp/udp的网络。为了实现这个目标，而无需专门评估每个寻址方案，LIBP2P使用MultiaDDR以**自我描述方式**为所有受支持的传输协议编码网络地址。[multiaddr格式以及其实现](https://github.com/multiformats/multiaddr)， 10 | 11 | 多地址在整个libp2p中用于编码网络地址。当地址需要在进程之间共享或交换时，它们被编码为multiaddr的二进制表示。 12 | 13 | 当交换地址时，对等端发送一个包含其网络地址和对等端id的多地址，格式如下： 14 | 15 | ``` 16 | /ip4/7.7.7.7/tcp/1234/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N 17 | ``` 18 | 19 | 多地址是可以遍历到某个目标的指令序列。 20 | 21 | 例如，/ip4/7.7.7.7/tcp/1234多地址以ip4开头，这是需要地址的最低级别协议。tcp协议运行在ip4之上，所以它是下一个。 22 | 23 | 上面的multiaddr由两个组件组成，/ip4/7.7.7.7组件和/tcp/1234组件。不可能再分开一个/仅ip4是无效的多地址，因为ip4协议被定义为需要32位地址。同样，tcp需要16位端口号。 24 | 25 | 尽管我们将/ip4/7.7.7.7和/tcp/1234称为较大tcp/IP地址的“组件”，但根据multiaddr规范，它们实际上都是有效的多地址。然而，并非每个语法上有效的多址都是网络中进程的功能描述。正如我们所看到的，即使是一个简单的TCP/IP连接也需要将两个多地址合并为一个。有关如何组合多地址的信息，请参阅“组合多地址”一节，有关描述有效传输地址的组合，请参阅传输多地址一节。 26 | 27 | multiaddr协议表包含所有当前定义的协议及其地址组件的长度。 -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕libp2p之安全通信.md: -------------------------------------------------------------------------------- 1 | # TLS 2 | 3 | TLS（传输层安全）是一种用于保护没有内建安全功能（例如TCP、WebSocket）的传输的安全握手协议之一。噪声（Noise）是TLS的替代方案，也是另一种用于保护传输的安全握手协议。 4 | 5 | ## 什么是TLS？ 6 | TLS是一种建立安全数据通道的加密协议。TLS提供加密、认证和数据完整性。 7 | 8 | 在TLS握手过程中，客户端和服务器之间建立了一个安全连接。握手完成后，双方都派生了一个密钥（TLS主密钥），只有这两个对话方知道该密钥，然后用于加密通过通道发送的应用程序数据。 9 | 10 | ## 什么是TLS 1.3？ 11 | TLS 1.3是TLS协议的一个新版本，于2018年在RFC 8446中发布。它比TLS 1.2带来了几个改进：**在典型情况下，握手的延迟从2个网络往返降至1个网络往返**；通过加密证书来改善隐私属性；并且简化协议以减少实现复杂性。 12 | 13 | ## 握手 14 | libp2p使用TLS 1.3握手来建立两个节点之间的安全连接。节点在握手期间会验证对方的libp2p对等ID。 15 | 16 | 在协议协商过程中，TLS 1.3可通过以下协议ID进行识别：/tls/1.0.0。 17 | 18 | 节点身份验证是通过将公钥编码到TLS证书中来完成的。我们设计了该系统以验证TLS不支持的密钥类型，如sepc256k1（一种可用于libp2p密钥的密钥类型）。 19 | 20 | 在处理TLS证书时，节点会从接收到的公钥中派生对等ID。发起连接的节点会检查其是否与其意图连接的节点的对等ID匹配。 21 | 22 | ## Noise 23 | 24 | Noise协议框架是一种广泛使用的加密方案，它通过将密码原语组合成具有可验证安全性质的模式来实现安全通信。 25 | 26 | 了解更多信息，请访问[https://noiseprotocol.org](https://noiseprotocol.org/)。 27 | 28 | ## libp2p中的Noise 29 | libp2p使用Noise协议框架对节点之间的数据进行加密并提供前向保密性。noise-libp2p是Noise协议框架的一种实现，**用于通过交换密钥和在libp2p握手过程中加密流量来建立两个节点之间的安全通道**。成功完成Noise握手后，生成的密钥通过安全通道发送密文消息。这些消息的线路格式和用于加密的密码原语在libp2p-noise规范中指定。 -------------------------------------------------------------------------------- /Learning_Roadmaps_And_Resources/相关学习资料（路线图和资料持续更新，建议关注）.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # 学习资料 4 | 5 | 初阶和中阶： 6 | 7 | - [炼就纯熟区块链开发技能，看这一篇就够了](https://mp.weixin.qq.com/s/1RGKEdcGhZbjqKv7LBrAVA) 8 | - [新人必读：区块链实用型技能树](https://mp.weixin.qq.com/s?__biz=MzA3MTI5Njg4Mw==&mid=2247485259&idx=1&sn=cc10c77034c33dd97f0205e561935417&chksm=9f2ef557a8597c4119e3fc103f6cf51f62cb4100d1d8293b9de2668ee0f6ca963fae06f05b0e&scene=21#wechat_redirect) 9 | - [FISCO BCOS开源文档（概念、安装部署、应用开发部分）](https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/) 10 | - [Solidity智能合约（中文）](https://solidity-cn.readthedocs.io/)（注意选择对应版本） 11 | - [《鸟哥的linux私房菜》（系列）](https://book.douban.com/subject/2208530/) 12 | - [《UNIX网络编程》（系列）](https://book.douban.com/subject/1500149/) 13 | - [《Java核心技术》（系列）](https://book.douban.com/subject/26880667/) 14 | - [《Springboot实战》](https://book.douban.com/subject/26857423/) 15 | - [《Spring实战》](https://book.douban.com/subject/26767354/) 16 | 17 | 18 | 19 | 高阶： 20 | 21 | > 因为是前沿方向，此部分建议基于中阶的资料深入研究，并基于开源项目去研读代码，进行实践，或者研读相关领域顶会论文。 22 | > 23 | > 阅读各部委等权威机构定期出版的区块链白皮书和蓝皮书，跟踪权威媒体的行业新闻，了解行业动态。 24 | > 25 | > 同时，但凡到了高阶阶段，搜寻资料，深入研究的方法应已经成型，无需过多推荐。 26 | 27 | 28 | 29 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/Polygon zkevm/核心组件.md: -------------------------------------------------------------------------------- 1 | ## sequencer 2 | 3 | - 将交易打包成batch，提交到L1 的合约上 （目前batch里只有一个交易，这也是方便生成证明） 4 | 5 | 6 | 7 | ## **Aggregator** （类似proposer） 8 | 9 | - 监听L1上的batch提交事件，会把batch交易同步到自己节点，然后发送给zkprover 10 | - 当收到zkprover的有效性证明，以及对应batch执行后的状态提交给L1的polygon zkevm 合约（类似validator）里 （状态谁给的？），实际上你可以把polygon zkevm 合约当做是共识层，因为只有验证通过才能进行下一步。 11 | 12 | 13 | 14 | ## zkprover 15 | 16 | - 接收到Aggregator 发过来的交易后，会为每个batch的每笔交易生成validity proof， 然后将多个batch里的每笔交易的proof聚合成一个新的总的validity proof 17 | - 当聚合了多个batch的validity proof 发送给Aggregator 18 | 19 | 20 | 21 | 22 | 23 | ## DAC 24 | 25 | Polygon 的cdk validium 是链下保存了交易数据，并没有发布数据到L1，只是整体数据的一个Hash值，所以有个DAC委员会专门验证sequencer提交的交易数据 ，实际就是sequencer提交了一堆交易，DAC需要进行校验是否有不存在的交易，他应该会从交易池中拉取交易，只要验证通过就会对这包交易数据进行签名，使用的事多签，m-out-of-n ,然后会把签名附加到交易数据的哈希值撒好难过，多签合约在L1上，可以验证 26 | 27 | 28 | 29 | ## Polygon CDK validium 流程 30 | 31 | - Sqequncer 收集交易并将其添加到区块中（这个是zkevm 本身的网络区块吗），然后将区块分批放入，同时递归计算其哈希值 32 | - 然后sequncer 将批量数据和相应的哈希值发到DAC，请求签名 33 | - DAC收到后会对每个批次哈希值进行验证并存储在DAC节点的本地数据库里，并为每个批次哈希生成签名 34 | - sequencer收集DAC成员的签名和原始批次哈希，提交到以太坊的多签合约中 35 | - aggregator 会为batch准备证明，然后提交到以太坊 36 | 37 | # reference 38 | 39 | https://foresightnews.pro/article/detail/32223 40 | 41 | -------------------------------------------------------------------------------- /Cross_Chain_Technology/跨链方案/跨链桥/cbridge.md: -------------------------------------------------------------------------------- 1 | ## SGN 2 | 3 | pos 链，对L1<->L2 交易进行共识，生成多重签名，表明跨链交易可行。 4 | 5 | SGN作为cBridge节点网关和服务水平协议（SLA）仲裁器 6 | 7 | ![image-20230506100319074](/Users/carver/Library/Application Support/typora-user-images/image-20230506100319074.png) 8 | 9 | SGN会监控cbride节点的状态和性能以及跨链陈功率等等指标，来将用户请求分发到合适的节点上， 对不能完成承诺的节点，进行惩罚 10 | 11 | ### SGN作为共享流动性池管理者 12 | 13 | ![image-20230506103544494](/Users/carver/Library/Application Support/typora-user-images/image-20230506103544494.png) 14 | 15 | 16 | 17 | ## SLA债券 18 | 19 | 你买的多，你作为节点被选中的概率大 20 | 21 | ## 节点选择规则 22 | 23 | 根据 SLA债券，节点响应时间，成功率 ，等作为因子来计算概率。 24 | 25 | ## cBridge 26 | 27 | a: 在不跑节点的情况下提供流动性 28 | 29 | 流动性池合约 30 | 31 | b:高流动性 32 | 33 | 流动性提供商需要放入规范练代币和另一个协议代币到链上AMM池 34 | 35 | ## 费用结构 36 | 37 | xAsset 模型中桥接代币的费用计算如下： 38 | 39 | 费用 = 基本费用 + 协议费 40 | 41 | 基本**费用**以代币转移的形式支付，包括将代币发送给用户的目标链 gas 成本。 42 | 43 | 协议**费用**与转账金额成正比，并支付给 State Guardian Network (SGN) 验证者和质押者以换取他们的服务。协议**费的**范围为总转账金额的 0% 至 0.5% 44 | 45 | ## 安全 46 | 47 | 两种安全模型： 48 | 49 | 根据延迟和安全假设不同 50 | 51 | 1. 来自optimism rollup的灵感 52 | 2. L1-PoS-blockchainL1-PoS-blockchain 53 | 54 | ## 端到端的工作流 55 | 56 | https://im-docs.celer.network/developer/architecture-walkthrough/end-to-end-workflow -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/椭圆曲线/椭圆曲线_性质及分类: -------------------------------------------------------------------------------- 1 | ## 椭圆曲线的性质 2 | 3 | 1. 非奇异性：椭圆曲线必须是非奇异的，也就是不存在重复的点或者有尖点的情况。这保证了椭圆曲线上所有操作的唯一性。 4 | 5 | 2. 微分微分方程：椭圆曲线可以使用微分方程来准确描述。椭圆曲线上的每个点都可以看做是微分曲线上的一个拐点。这种微分方程的性质是非常有用的，因为它能够在数学上描述椭圆曲线的特性，例如切线和斜率。 6 | 7 | 3. 展开性：对于一个指定的椭圆曲线，我们可以通过无限个定理来描述它。这些公式包括基本定理、塔特纳定理、黎曼-罗赫定理、数学基本定理和法雷定理等。所有这些定理都揭示了椭圆曲线的一些独特性质。 8 | 9 | 4. 结合律和交换律：在椭圆曲线上的点加法运算满足结合律和交换律，这是使椭圆曲线成为一种适合密码学应用的重要性质。这些性质允许我们在椭圆曲线上构建密钥协商和签名算法等密码学方案。 10 | 11 | ## 椭圆曲线的分类 12 | 13 | ### 含奇数系数的椭圆曲线 14 | 15 | 此类椭圆曲线的方程是类似于这样的形式：$y^2 = x^3 + ax + b$，其中a和b都是实数。当a和b都是整数时，这个椭圆曲线可以用于密码学领域。这种类型的椭圆曲线又可以分为两个子类型：安全和非安全。 16 | 17 | 安全型椭圆曲线：这种类型的椭圆曲线具有合适大小的阶，所以它们是在密码学中使用的最好的椭圆曲线。 18 | 19 | 非安全型椭圆曲线：这种类型的椭圆曲线的阶太小，它们不能用作有效的加密方法。但是，它们可以用于一些特殊情况下的机密性问题。 20 | 21 | ### 含偶数系数的椭圆曲线 22 | 23 | 这种类型的椭圆曲线可以被写成以下形式：$y^2=x(x^2+c)$，其中c是一个实数。类似于前一种类型，含偶数系数的椭圆曲线可以分为安全和非安全型。 24 | 25 | 安全型椭圆曲线：这是在密码学中使用的最好的椭圆曲线之一。安全型椭圆曲线是数学上合适大小的阶和运算时最快的。 26 | 27 | 非安全型椭圆曲线：这种类型的椭圆曲线的阶太小，所以不能被用作密码体系。但是，它们可以用于测试加密算法的性能。 28 | 29 | ### 超奇异椭圆曲线 30 | 31 | 超奇异椭圆曲线被写成以下形式：$y^2 + xy = x^3 + ax^2 + b$，其中a和b是整数或者有理数。这种类型的椭圆曲线常常在椭圆曲线密码学中没有用处，但是许多人使用它们来在数学中做研究和提高效率。 32 | 33 | ### 特殊椭圆曲线 34 | 35 | 特殊椭圆曲线很少使用专业领域，是一个非常小的类别，存在堪称例外的椭圆曲线。 36 | 37 | 在实际应用中，为了保证密钥安全性，我们需要使用具有足够大的阶的安全型椭圆曲线。同时，我们也需要考虑这种椭圆曲线的计算资源消耗。 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/安全多方计算/VSS协议.md: -------------------------------------------------------------------------------- 1 | VSS（Verifiable Secret Sharing）秘密共享协议是一种安全的分布式算法，用于将秘密（如密钥）分割成多个份额，然后将这些份额分配给不同的参与方。只有在获得足够数量的份额时才能重建原始秘密。 2 | 3 | VSS协议由多个参与方共同完成，其中至少需要t+1个参与方才能重构原始秘密，其中t为恶意参与方的数量。即，只要有少于t+1个恶意参与方，那么原始秘密就可以被恢复。此外，VSS协议还具有可验证性，因此每个参与方都可以证明它们的份额确实是由原始秘密生成的。 4 | 5 | 在VSS协议中，首先需要选择一个大素数p和一个生成元g，然后将密钥k分解成k = k_0 + k_1，其中k_0和k_1都是随机数，并且k_0是在每个参与方之间共享的秘密。然后，每个参与方i都生成一个随机数r_i，并计算出g^{r_i} 和 h_i = k_0 g^{r_i} + k_1 g^{r_i}，将其发送给其他参与方。 6 | 7 | 然后，每个参与方都可以计算出h = Π_{i=1}^{n} h_i^{λ_i}，其中λ_i是Lagrange插值多项式中的系数，以确保对于每个i，当计算h时，只考虑到参与方i的份额。如果只有t个参与方，那么由于我们需要至少t+1个份额才能重构原始密钥，因此必须忽略不诚实的参与方的份额，以避免泄漏原始密钥。 8 | 9 | 最后，通过计算h和k_0之间的比率，可以得到k_1的值，从而重构原始密钥。此外，每个参与方都可以使用自己的份额来验证其它参与方的份额是否真实，并且确保h是正确计算的。 10 | 11 | VSS（Verifiable Secret Sharing）协议在实际工程应用中有许多场景，以下是其中几个常见的应用场景： 12 | 13 | 1. 加密货币钱包：在加密货币钱包中，密钥的安全性非常重要。使用VSS协议将密钥分割成多个份额，并分配给不同的参与方，以确保密钥只有在获得足够数量的份额时才能被重构，从而保护用户的资产安全。 14 | 2. 多方数据共享：在多方数据共享场景中，多个参与方需要共享敏感数据，但又不想将所有数据集中存储在一个地方。使用VSS协议将数据分割成多个份额，并分配给不同的参与方，以确保只有在获得足够数量的份额时才能重构原始数据。 15 | 3. 分布式密钥管理系统：在分布式系统中，多个节点需要共同管理密钥，使用VSS协议将密钥分割成多个份额，并分配给不同的参与方，以确保密钥只有在获得足够数量的份额时才能被重构，从而保护密钥的安全性。 16 | 4. 分布式存储系统：在分布式存储系统中，多个节点需要共同存储数据，使用VSS协议将数据分割成多个份额，并分配给不同的节点，以确保只有在获得足够数量的份额时才能重构原始数据，从而保护数据的安全性。 17 | 18 | 总之，VSS协议可以用于各种需要保护秘密的场景，特别是需要多方参与的场景，使得秘密的分配和管理更加安全可靠。 -------------------------------------------------------------------------------- /Cross_Chain_Technology/跨链方案/跨链桥/桥概念.md: -------------------------------------------------------------------------------- 1 | - **Native bridges** 2 | - 验证器或基于预言机的桥接器–这些桥接器依赖于外部验证器集或预言机来验证跨链传输 ： Multichain and Across. 3 | - 通用消息传递桥–这些桥可以跨链传输资产以及消息和任意数据。示例：Nomad和LayerZero 4 | - 流动性网络——这些桥梁主要集中于通过原子交换将资产从一个链转移到另一个链。一般来说，它们不支持跨链消息传递。例如：Connext和Hop。 5 | 6 | 7 | 8 | 设计桥考虑的问题： 9 | 10 | 有了桥梁，就没有完美的解决方案。相反，只有为了实现一个目的而进行的权衡。开发人员和用户可以根据以下因素对桥梁进行评估： 11 | 12 | 安全性–谁验证系统？由外部验证器保护的网桥通常不如由区块链验证器本地或本地保护的网桥安全。 13 | 14 | 便利性–完成一笔交易需要多长时间，用户需要签署多少笔交易？对于开发人员来说，集成一个桥需要多长时间，过程有多复杂？ 15 | 16 | 连通性——一座桥可以连接哪些不同的目的地链（即汇总、侧链、其他第1层区块链等），集成一个新的区块链有多难？ 17 | 18 | 传递更复杂数据的能力–桥接器是否可以跨链传输消息和更复杂的任意数据，还是只支持跨链资产传输？ 19 | 20 | 成本效益–通过桥接跨链转移资产的成本是多少？通常，桥梁根据天然气成本和特定路线的流动性收取固定或可变费用。根据确保桥梁安全所需的资金来评估桥梁的成本效益也是至关重要的。 21 | 22 | 23 | 24 | 受信任–受信任的网桥经过外部验证。他们使用一组外部验证器（具有多西格的联邦、多方计算系统、oracle网络）来跨链发送数据。因此，它们可以提供良好的连接，并实现跨链的全面通用消息传递。它们在速度和成本效益方面也往往表现良好。这是以安全性为代价的，因为用户必须依赖网桥的安全性。 25 | 26 | 无信任–这些网桥依赖于它们所连接的区块链及其验证器来传输消息和令牌。它们是“不可信的”，因为它们不添加新的信任假设（除了区块链）。因此，无信任网桥被认为比可信网桥更安全。 27 | 28 | 29 | 30 | 要基于其他因素评估不信任的桥梁，我们必须将其分解为广义的消息传递桥梁和流动性网络。 31 | 32 | 通用消息传递桥–这些桥在安全性和跨链传输更复杂数据的能力方面表现出色。通常，它们在成本效益方面也很好。然而，这些优势通常是以轻型客户端网桥（如IBC）的连接为代价的，而使用欺诈证据的乐观网桥（如Nomad）的速度则存在缺陷。 33 | 34 | 流动性网络——这些桥使用原子交换来转移资产，并且是经过本地验证的系统（即，它们使用底层区块链的验证器来验证交易）。因此，他们在安全性和速度方面表现出色。此外，它们被认为具有相对的成本效益，并提供良好的连接。然而，主要的折衷是它们无法传递更复杂的数据，因为它们不支持跨链消息传递。 -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/cosmos/cosmos开发者.md: -------------------------------------------------------------------------------- 1 | 1. 他的多链架构可以让一个应用程序在不同的IBC协调的链上并行运行，无论是否由相同的验证器集运行。这种跨链的水平可扩展性理论上允许无限的类似垂直的可扩展性，减去协调开销。 2 | 3 | 2. *Hub zone,我们如何将我们的链连接到非 Tendermint 链？*IBC 连接不限于基于 Tendermint 的链。如果另一个非 Tendermint 区块链使用快速最终共识算法，则可以通过使 IBC 适应非 Tendermint 共识机制来建立连接。 4 | 5 | 如果另一条链是**概率确定性链**，则 IBC 的简单改编是不够的。称为**peg-zone**的代理链有助于建立互操作性。Peg-zones 是快速终结性区块链，它跟踪链状态以建立终结性。peg-zone 链本身是 IBC 兼容的，并充当IBC 网络其余链和概率最终链之间的**桥梁。** 6 | 7 | 3. CLI命令构建区块链 8 | 9 | 4. cosmos wasm 一个用于开发和测试智能合约的多链平台 10 | 11 | 5. Ethemint将EVM作为SDK模块 12 | 13 | 6. 质押atom 获取收益 14 | 15 | 7. [Althea Testnet 存储库：Gravity Bridge](https://github.com/gravity-bridge/gravity-bridge) （cosmos上面的跨链桥）， 将 Cosmos 与以太坊连接起来，并允许在基于 Cosmos 的区块链之间传输 ERC-20 代币。 16 | 17 | 8. 针对私有链之间的跨链通信https://www.hyperledger.org/blog/2021/06/09/meet-yui-one-the-new-hyperledger-labs-projects-taking-on-cross-chain-and-off-chain-operations 18 | 19 | 9. cosmos的相关所有库文件 https://github.com/cosmos/awesome-cosmos 20 | 21 | 10. IBC支持同构链和异构链，支持非最终一致性和最终一致性链互相跨链 22 | 23 | 11. https://youtu.be/OSMH5uwTssk 允许无数主权区块链之间的互操作性的方法以及如何构建与 IBC 兼容的应用程序进行了演讲。 24 | 25 | 12. https://youtu.be/zUVPkEzGJzA 他解释了如何使用区块链间通信 (IBC) 协议连接不同的区块链，特别关注轻客户端、连接、通道, 和数据包承诺 26 | 27 | 13. 跨链账户概念 28 | 29 | 14. https://youtu.be/X5mPQrCLLWE 他研究了 IBC 数据包生命周期和轻客户端的安全属性 -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕p2p网络之NAT传输.md: -------------------------------------------------------------------------------- 1 | > https://www.jianshu.com/p/f71707892eb2 2 | 3 | 4 | 5 | ## NAT简介 6 | 7 | NAT（Network Address Translation，网络地址转换），也叫做网络掩蔽或者IP掩蔽。NAT是一种网络地址翻译技术，主要是将内部的私有IP地址（private IP）转换成可以在公网使用的公网IP（public IP） 8 | 9 | 10 | 11 | ## NAT类型 12 | 13 | 在[STUN](https://info.support.huawei.com/info-finder/encyclopedia/zh/STUN.html)标准中，根据私网IP地址和端口到NAT出口的公网IP地址和端口的映射方式，把NAT分为如下四种类型，详见下图。 14 | 15 | ![image-20221014180441215](https://tva1.sinaimg.cn/large/008vxvgGgy1h74z5hxjujj311y0q042f.jpg) 16 | 17 | 18 | 19 | ### 完全锥型NAT 20 | 21 | 所有从同一个私网IP地址和端口（IP1:Port1）发送过来的请求都会被映射成同一个公网IP地址和端口（IP:Port）。并且，任何外部主机通过向映射的公网IP地址和端口发送报文，都可以实现和内部主机进行通信。 22 | 23 | 这是一种比较宽松的策略，只要建立了私网IP地址和端口与公网IP地址和端口的映射关系，所有的Internet上的主机都可以访问该NAT之后的主机。 24 | 25 | ### 限制锥型NAT 26 | 27 | 所有从同一个私网IP地址和端口（IP1:Port1）发送过来的请求都会被映射成同一个公网IP和端口号（IP:Port）。与完全锥型NAT不同的是，当且仅当内部主机之前已经向公网主机发送过报文，此时公网主机才能向私网主机发送报文。 28 | 29 | ### 端口限制锥型NAT 30 | 31 | 与限制锥型NAT很相似，只不过它包括端口号。也就是说，一台公网主机（IP2:Port2）想给私网主机发送报文，必须是这台私网主机先前已经给这个IP地址和端口发送过报文。 32 | 33 | ### 对称NAT 34 | 35 | 所有从同一个私网IP地址和端口发送到一个特定的目的IP地址和端口的请求，都会被映射到同一个IP地址和端口。如果同一台主机使用相同的源地址和端口号发送报文，但是发往不同的目的地，NAT将会使用不同的映射。此外，只有收到数据的公网主机才可以反过来向私网主机发送报文。 36 | 37 | 这和端口限制锥型NAT不同，端口限制锥型NAT是所有请求映射到相同的公网IP地址和端口，而对称NAT是不同的请求有不同的映射。 38 | 39 | ## NAT工作原理 40 | 41 | -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/cosmos/Cosmos sdk/cosmos_init.md: -------------------------------------------------------------------------------- 1 | Newrootcmd-newApp->app.new 2 | 3 | 4 | 5 | App.new 做的事情: 6 | 7 | - Codec 创建 8 | 9 | - interfaceRegistry 创建 🚩 10 | 11 | - baseapp创建 12 | 13 | - 存储创建包括db,以及CommitMultiStore 14 | - 定义模块路由器，包含本机查询路由以及本机消息服务处理路由和grpc消息服务以及grpc消息处理路由 15 | 16 | - 创建目前的kvstorekeys 17 | 18 | - 初始化paramskeeper🚩 19 | 20 | - add capability keeper and ScopeToModule for ibc module 🚩 21 | 22 | - 添加各个模块的keeper 23 | 24 | - 创建模块管理器 25 | 26 | - app.mm.SetOrderBeginBlockers 27 | 28 | - app.mm.SetOrderEndBlockers 29 | 30 | - app.mm.SetOrderInitGenesis 31 | 32 | - 通过模块管理器注册所有模块的不变量，如果某些值变了可能会触发链停 33 | 34 | - 注册消息路由和查询路由，目前已经废弃掉了，使用RegisterServices 35 | 36 | - 创建模块管理器配置器，配置msgServer和queryServer🚩 37 | 38 | - 通过模块管理器注册所有模块的服务 39 | 40 | - 注册服务包括两个，一个是消息服务，一个是查询服务 41 | 42 | ```go 43 | // 第一个参数是服务定义（切片），第二个就是handlers，也就是对应的msgServer里面的定义个各个实现 44 | types.RegisterMsgServer(cfg.MsgServer(), keeper.NewMsgServerImpl(am.keeper)) 45 | types.RegisterQueryServer(cfg.QueryServer(), am.keeper) 46 | ``` 47 | 48 | - 创建 SimulationManager 49 | 50 | - 初始化存储 51 | 52 | - 初始化Baseapp 53 | 54 | - app.SetInitChainer(app.InitChainer) 55 | - app.SetBeginBlocker(app.BeginBlocker) 56 | - app.SetAnteHandler(anteHandler) 57 | - -------------------------------------------------------------------------------- /DApp_Development/安全审计/合约漏洞/重入攻击手段.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | ## 重入攻击类型 6 | 7 | 1. 单函数重入 8 | 2. 跨函数重入 9 | 3. 跨合约重入 10 | 11 | 12 | 13 | ### 单函数重入 14 | 15 | ### 跨函数重入 16 | 17 | ### 跨合约重入 18 | 19 | 20 | 21 | ## 避免重入攻击 22 | 23 | ### 互斥锁模式 24 | 25 | ```solidity 26 | uint private unlocked = 1; 27 | modifier lock() { 28 | require(unlocked == 1, 'UniswapV2: LOCKED'); 29 | unlocked = 0; 30 | _; 31 | unlocked = 1; 32 | } 33 | ``` 34 | 35 | 段代码定义了一个名为`lock`的函数修饰器（modifier）。由于这个修饰器是在智能合约内定义的，在智能合约内，可以把修饰器看成是一个包裹函数，它会包裹在被修饰的函数外面。 36 | 37 | 这个修饰器的主要作用就是在被修饰的函数执行时防止重入攻击。重入攻击指的是当一个智能合约在执行一个函数时，又会出发同一个或另一个合约的调用，如果不加控制地一直递归执行下去，可能会导致合约出现重复执行或者数据错误等问题。 38 | 39 | 具体来说，这个修饰器会首先判断变量`unlocked`的值是否为1，只有在`unlocked`等于1时，才允许调用被修饰的函数。然后，修饰器会将`unlocked`的值修改为0，并执行被修饰的函数（用`_`表示）。最后，被修饰的函数执行结束后，修饰器会再将`unlocked`的值修改为1，以便下次调用。 40 | 41 | 这种设计可以保证，在被修饰的函数执行期间，其他合约调用该合约的同一个函数时，都会被拒绝，从而避免了重入攻击的发生。 42 | 43 | 需要注意的是，在使用这个修饰器的时候，需要定义一个名为`unlocked`的全局变量，并且需要在智能合约的其他地方修改`unlocked`的值。这个变量是用来控制修饰器的执行行为的。 44 | 45 | ## 参考 46 | 47 | https://www.aqniu.com/vendor/88702.html 48 | 49 | https://paper.seebug.org/632/ 50 | 51 | https://www.cnblogs.com/wanghui-garcia/p/9580573.html solidity安全开发指南 52 | 53 | https://consensys.github.io/smart-contract-best-practices/development-recommendations/general/external-calls/#favor-pull-over-push-for-external-calls 54 | -------------------------------------------------------------------------------- /Privacy_Computing/安全多方计算/安全多方计算学习路径.md: -------------------------------------------------------------------------------- 1 | 1. 学习基础知识： 2 | - 学习密码学基础，包括对称加密、非对称加密、哈希函数、数字签名等。 3 | - 了解安全多方计算的基本概念，如隐私保护、安全计算、安全性定义等。 4 | - 学习安全多方计算的应用场景，例如隐私保护的数据挖掘、保密投票等。 5 | 2. 阅读经典论文和书籍： 6 | - 阅读 Andrew Yao 的经典论文 "Protocols for secure computations"，了解两方安全计算的最早理论。 7 | - 阅读书籍 "Secure Multiparty Computation and Secret Sharing"（作者：Ronald Cramer, Ivan Damgård 和 Jesper Buus Nielsen），了解安全多方计算的基本理论和技术。 8 | - 应用密码学》(Applied Cryptography) by Bruce Schneier 9 | - 《密码学基础》(Cryptography: Theory and Practice) by Douglas R. Stinson 10 | - 《密码学的数学基础》(Mathematical Foundations of Public Key Cryptography) by Richard A. Mollin 11 | - 《密码学导论》(Introduction to Cryptography) by Johannes A. Buchmann 12 | 3. 学习安全多方计算的核心协议： 13 | - 学习 Yao 的加密电路（Yao's Garbled Circuits）协议，了解如何使用加密电路进行两方安全计算。 14 | - 学习 BGW（Ben-Or, Goldwasser, and Wigderson）协议和 GMW（Goldreich, Micali, and Wigderson）协议，了解多方安全计算的基本框架。 15 | - 学习 Shamir's Secret Sharing 和 Additive Secret Sharing 等秘密共享方案，理解如何将数据分割成多份以实现安全计算。 16 | 4. 探索高效的安全多方计算技术： 17 | - 了解 Oblivious Transfer（OT）和 Oblivious RAM（ORAM）等隐私保护技术，探究它们在安全多方计算中的应用。 18 | - 学习全同态加密（FHE）和部分同态加密（PHE）方案，了解它们如何实现安全计算。 19 | - 探索零知识证明（ZKP）技术，了解其在保护隐私计算中的应用。 20 | 5. 学习实用的安全多方计算框架和工具： 21 | - 学习开源框架，如 Sharemind、MP-SPDZ、FRESCO 等，了解它们的设计理念和使用方法。 22 | - 学习如何使用这些框架进行安全多方计算实验，例如实现安全的线性回归、神经网络计算等。 23 | 6. 安全多方计算应用 24 | - 隐私保护 25 | - 数据合作计算 26 | - 安全投票 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/密码学中的数学/数论基础/数论_欧拉定理.md: -------------------------------------------------------------------------------- 1 | 欧拉定理（Euler's Theorem）是数论中的一个重要定理，由瑞士数学家莱昂哈德·欧拉（Leonhard Euler）提出。欧拉定理是费马小定理的推广，涉及到模运算和欧拉函数。以下是欧拉定理的陈述、证明和应用的详细解释： 2 | 3 | ## 欧拉定理的陈述 4 | 5 | 对于任意整数a和正整数m，如果a和m互质（即它们的最大公约数为1），那么满足以下关系 6 | 7 | ``` 8 | a^φ(m) ≡ 1 (mod m) 9 | ``` 10 | 11 | 其中，φ(m)表示m的欧拉函数值，即小于m且与m互质的正整数的个数。 12 | 13 | ## 欧拉定理的证明 14 | 15 | 欧拉定理的证明可以基于乘法群和欧拉函数的性质。以下是证明过程： 16 | 17 | 假设我们有一个模m下的乘法群G，包含所有与m互质的正整数。根据欧拉函数的定义，G中有φ(m)个元素。我们可以将G中的元素表示为`{x1, x2, ..., xφ(m)}`。 18 | 19 | 现在考虑将乘法群G中的每个元素都乘以a，得到一个新的集合`{ax1, ax2, ..., axφ(m)}`。由于a和m互质，新集合中的元素在模m下两两不同余。 20 | 21 | 类似于费马小定理的证明过程，我们可以得出新集合与原始乘法群在模m下是相同的，只是元素的顺序发生了变化。因此，两个集合的乘积在模m下是相等的： 22 | 23 | ``` 24 | x1 * x2 * ... * xφ(m) ≡ a * x1 * a * x2 * ... * a * xφ(m) (mod m) 25 | ``` 26 | 27 | 将等式两边都除以原始乘法群的乘积，我们得到： 28 | 29 | ``` 30 | a^φ(m) * x1 * x2 * ... * xφ(m) ≡ x1 * x2 * ... * xφ(m) (mod m) 31 | ``` 32 | 33 | 由于`x1, x2, ..., xφ(m)`都与m互质，它们在模m下都有乘法逆元。我们可以将等式两边分别乘以`x1, x2, ..., xφ(m)`的乘法逆元，得到： 34 | 35 | ``` 36 | a^φ(m) ≡ 1 (mod m) 37 | ``` 38 | 39 | ## 欧拉定理的应用 40 | 41 | 欧拉定理在数论、密码学和计算机科学等领域具有广泛的应用，以下是一些主要应用： 42 | 43 | 1. **计算模运算的逆元**：欧拉定理可以用来计算模运算的逆元。对于一个与正整数m互质的整数a，它在模m下的逆元为`a^(φ(m)-1)`。这是因为根据欧拉定理，我们有`a^φ(m) ≡ 1 (mod m)`。将等式两边都除以a，我们得到`a^(φ(m)-1) ≡ a^(-1) (mod m)`。 44 | 2. **同余方程**：欧拉定理可以用于解决同余方程问题，特别是模运算的指数同余方程。通过将同余方程与欧拉定理结合，我们可以将问题转化为求解模m下的逆元或对欧拉函数φ(m)取模。 45 | 3. **加密算法**：欧拉定理在加密算法中发挥着关键作用，如RSA加密算法和ElGamal加密算法等。这些算法的安全性基于模运算的性质以及欧拉定理。 46 | 4. **编程竞赛和算法**：在编程竞赛和算法设计中，欧拉定理常用于解决涉及模运算和指数运算的问题。通过应用欧拉定理，我们可以在许多情况下优化算法，提高计算速度。 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/密码学中的数学/数论基础/数论_素数与素数分布.md: -------------------------------------------------------------------------------- 1 | ## 素数（Prime Numbers） 2 | 3 | 素数是指大于1的自然数，其仅有两个因数：**1和它本身**。换句话说，一个素数不能被任何其他数（除了1和它本身）整除。 4 | 5 | 例如，前几个素数是： 6 | 7 | ``` 8 | 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, ... 9 | ``` 10 | 11 | 注意，1不是素数，因为它只有一个因数（即1本身）。 12 | 13 | ## 素数的性质 14 | 15 | 素数具有许多有趣的性质，以下是一些主要的性质： 16 | 17 | 1. **无穷性**：素数的数量是无限的。这一事实最早由古希腊数学家欧几里得证明。 18 | 2. **最小素数**：2是最小的素数，也是唯一的偶数素数。所有其他偶数都可以被2整除，因此它们不是素数。 19 | 3. **孪生素数**：孪生素数是一对素数，它们之间的差为2（例如，(3, 5)、(11, 13)和(17, 19)）。孪生素数猜想是一个著名的未解问题，它猜测存在无穷多对孪生素数。 20 | 4. **素数分布**：素数在整数中的分布遵循某种规律，但这个规律并不明显。素数定理给出了素数分布的一个近似表达式。 21 | 5. **素数的算术**：根据算术基本定理，任何大于1的自然数都可以唯一地分解为素数的乘积。这意味着素数是整数的“基本组成单位”。 22 | 23 | ## 素数测试 24 | 25 | 确定一个给定的数是否为素数是许多数学和计算问题的基础。以下是一些素数测试方法： 26 | 27 | 1. **试除法**：对给定数n，从2到√n进行遍历，如果在这个范围内没有找到整除n的数，则n为素数。 28 | 29 | 2. **费马小定理**：如果对于正整数a和素数p，满足a^(p-1) ≡ 1 (mod p)，那么p可能是素数。费马测试并不是绝对准确的，存在一些“伪素数”能通过测试但实际上不是素数。 30 | 31 | 3. **米勒-拉宾素性测试**：米勒-拉宾测试是一种概率性素数测试，通过一定次数的随机测试来判断一个数是否为素数。它可以在短时间内找出大概率为素数的数，但它仍然存在一定的错误率。 32 | 33 | 4. **AKS素性测试**：AKS素性测试是一种确定性素性测试，提供了一个多项式时间的素数判断算法。与米勒-拉宾测试和费马测试不同，AKS素性测试可以在有限时间内准确判断一个数是否为素数。然而，实际应用中，AKS测试的速度较慢，通常不用于大数的素性测试。 34 | 35 | ## 素数在现实应用中的重要性 36 | 37 | 素数在现代密码学和计算领域具有广泛的应用。以下是一些著名的应用： 38 | 39 | 1. **RSA加密**：RSA加密算法是一种非对称加密算法，它依赖于两个大素数的乘积作为加密密钥。由于大素数的乘积很难被因数分解，因此RSA算法在合适的参数下具有很高的安全性。 40 | 2. **随机数生成**：素数在某些伪随机数生成器（如线性同余生成器）中起着关键作用，可以提高生成的随机数序列的质量和安全性。 41 | 3. **编码理论**：素数在编码理论中也有重要应用，如循环冗余校验（CRC）和循环码等。 42 | 43 | 总之，素数在数学、计算机科学和现实生活中具有许多有趣的性质和广泛的应用。数学家和研究人员仍在努力发现素数的更多规律和应用，以推动科学和技术的进步。 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/椭圆曲线/椭圆曲线_定义及点加运算.md: -------------------------------------------------------------------------------- 1 | ## 椭圆曲线的数学定义 2 | 3 | 椭圆曲线是一个在平面上的曲线，定义为所有满足以下方程的点(x, y)所组成的集合： 4 | 5 | $$y^2 = x^3 + ax + b$$ 6 | 7 | 其中a, b为常数，同时这个方程必须满足 威尔斯定理： 8 | 9 | 1. 这个曲线必须是光滑的，也就是说，不允许出现尖点或者被角。 10 | 2. 这个曲线必须是非奇异的，也就是不存在重复的点。 11 | 3. 所有曲线上的点必须在一条直线上有限的集合，即曲线不能无限延伸。 12 | 13 | 椭圆曲线的定义中，我们要特别注意的是参数 a 和 b，它们决定了曲线的形态。需要注意的是，一旦确定了 a 和 b 的取值，这个椭圆曲线就完全固定了下来。 14 | 15 | ## 椭圆曲线上的点加法运算 16 | 17 | 在椭圆曲线上有两种运算：点加（point addition）和标量乘法（scalar multiplication）。我们首先来介绍点加运算。 18 | 19 | 假设有两个点 P 和 Q, P = (x1, y1), Q = (x2, y2)， 为了求出它们的和 P + Q，我们需要通过一条直线求出它们的交点 R。关于如何通过两个点来求出一条直线，我们可以使用中点公式： 20 | 21 | $$x = (\frac{y_2 - y_1}{x_2 - x_1})^2 - x_1 - x_2$$ 22 | $$y = (\frac{y_2 - y_1}{x_2 - x_1})(x - x_1) - y_1$$ 23 | 24 | 当点 P 和 Q 相同时，我们需要使用切线来求出它们的和。 25 | 26 | 当椭圆曲线上的点比较多时，点加运算会相对麻烦，而且存在基于中心点的不对称问题。因此，我们可以通过使用雅可比坐标系来解决这个问题，使用雅可比坐标系可以将点加速为常数时间。 27 | 28 | 在雅可比坐标系下，我们定义一个点 (x,y,z) 表示为 (x/z^2，y/z^3)。 对于一个椭圆曲线上的点 P1 和 P2，我们通过以下公式来计算它们的和： 29 | 30 | $$s = \frac{(y2 - y1)z1 - (y2 - y1)z2}{(x2 - x1)z1^2 - (x2 - x1)z2^2}$$ 31 | $$x3 = s^2 - x1 - x2$$ 32 | $$y3 = s*x3 + y1 + s(x3 - x1)$$ 33 | $$z3 = z1 * z2 * (x1 - x2)^3$$ 34 | 35 | 这就是在雅可比坐标系下，计算椭圆曲线上两个点的加法。 36 | 37 | ## 示例 38 | 39 | 以下是一个简单的双曲线椭圆曲线的图示，箭头表示点加运算。两个点 P 和 Q 的和为 R。 40 | 41 | ![椭圆曲线上的点加法示例](https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Elliptic_curve_addition_visualisation.gif/800px-Elliptic_curve_addition_visualisation.gif) 42 | 43 | ## 结论 44 | 45 | 椭圆曲线是许多密码学算法的基础，例如椭圆曲线密钥交换（ECDH）和数字签名算法（ECDSA）。了解如何在椭圆曲线上进行点加运算是深入学习这些算法的基础。 -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/生态.md: -------------------------------------------------------------------------------- 1 | - [看看你有哪些可以申领的空投和 POAP](https://claimable.vercel.app/) 2 | - [MarketMake](https://hack.ethglobal.co/marketmake/showcase) 和 [EthDenver](https://ethdenver2021.devfolio.co/submissions) 的黑客松作品，以及 [MarketMake](https://twitter.com/ETHGlobal/status/1359600343152287745) 和 [EthDenver](https://medium.com/ethdenver/ethdenver-coloradojam-2021-bounty-track-quadratic-funding-winners-805cf5f2de76) 的优胜作品 3 | - Coingecko 现已支持[将 token 信息快速导入 MetaMask](https://twitter.com/coingecko/status/1358724757110276099) 4 | - Etherscan [现已支持显示标准类型交易的成本](https://twitter.com/etherscan/status/1358829488994283525) 5 | - Secureum 写了更多教程[教大家怎么看审计报告](https://secureum.substack.com/p/making-cover-safu-secureum-5) 6 | - 虽然大家一直都知道 EIP-1559 是有史以来最受欢迎的 EIP，但还是有一个 [#SupportEIP1559 运动](https://supporteip1559.org/) 7 | - [几个可能令 eth staker 难堪的事实](https://www.symphonious.net/2021/02/13/hard-truths-for-eth-stakers/) 8 | - ETHIndia (ETHGlobal) [12 个入围项目](https://twitter.com/ETHGlobal/status/1603833092346609700) 9 | - ConsenSys发布zkEVM（EVM 等效） 私有测试网 10 | - MailChain 支持 ENS 发送邮件 11 | - Rollups 网络交易量接近以太坊主网 12 | - [以太坊的随机数](https://www.paradigm.xyz/2023/01/eth-rng)使用SNARKs和VDFs 13 | - 使用[Nym来匿名化RPC调用]的概念证明(https://github.com/EdenBlockVC/spook) 14 | - [PeltaShield](https://pelta.tech/quick-setup.html)：通过RPC调用模拟你的交易的工具 15 | - [Ethunwrapp](https://ethunwr.app/)：回顾你在2022年的链上活动 16 | - [Zkitter](https://mirror.xyz/privacy-scaling-explorations.eth/P4jDH1gLrVQ-DP5VyIKQrlPAJUTDhtXZkFl2vp8ewSg)：可以用你的用户名或匿名发帖，公钥写在Arbitrum上用来以恢复账户。使用了各种zk工具： Interep, RLN, Semaphore -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/密码学中的数学/数论基础/数论_整数与除法.md: -------------------------------------------------------------------------------- 1 | 整数与除法是数学基础概念，这里是关于它们的详细解释： 2 | 3 | ## 整数（Integers） 4 | 5 | 整数是数学中最基本的概念之一，包括正整数、负整数和零。正整数是大于零的整数（如1，2，3...），负整数是小于零的整数（如-1，-2，-3...），零既不是正数也不是负数。 6 | 7 | 整数具有以下性质： 8 | 9 | 1. 封闭性：整数的加法、减法和乘法运算结果仍为整数。 10 | 2. 结合律：对于任意整数a、b和c，(a + b) + c = a + (b + c) 且 (a * b) * c = a * (b * c)。 11 | 3. 交换律：对于任意整数a和b，a + b = b + a 且 a * b = b * a。 12 | 4. 分配律：对于任意整数a、b和c，a * (b + c) = a * b + a * c。 13 | 5. 存在加法和乘法单位元：存在整数0和1，使得对于任意整数a，a + 0 = a 且 a * 1 = a。 14 | 6. 存在加法逆元：对于任意整数a，存在整数-b，使得a + (-b) = 0。 15 | 16 | ## 除法（Division） 17 | 18 | 除法是数学中的一种基本运算，用来求一个数被另一个数整除的商和余数。对于任意两个整数a和b（b ≠ 0），我们可以将a除以b，得到商q和余数r，满足以下关系： 19 | 20 | ``` 21 | a = b * q + r 22 | ``` 23 | 24 | 其中`0 ≤ r < |b|`。这里，q称为商，r称为余数。 25 | 26 | 例如，当a = 17，b = 5时，我们可以得到： 27 | 28 | ``` 29 | 17 = 5 * 3 + 2 30 | ``` 31 | 32 | 所以，商q = 3，余数r = 2。 33 | 34 | 除法有以下性质： 35 | 36 | 1. 唯一性：对于任意整数a和非零整数b，存在唯一的整数商q和余数r满足上述关系。 37 | 2. 除法算术：除法与加法和乘法有关，满足a = b * q + r这一关系。 38 | 3. 若a能被b整除（即余数为0），则我们称a是b的倍数，b是a的因数。 39 | 40 | 注意：在整数范围内，除法不满足封闭性、结合律、交换律和分配律。例如，5除以2的商不是整数，所以整数除法不满足封闭性。 41 | 42 | ## 最大公约数 43 | 44 | 最大公约数（GCD）是指两个或多个整数共有约数中最大的一个，记为**gcd(a,b)**。其中，a和b是非零整数，且不同时为0。 45 | 46 | 最大公约数的计算方法有很多种，其中辗转相除法是最常用的一种。具体步骤如下： 47 | 48 | 1. 如果a Cosmos-sdk 2 | > 3 | > Tendermint core 0.33.3 4 | > 5 | > cosmo-sdk 0.38.4 6 | > 7 | > Iavl 0.13.3 8 | > 9 | > Gaia 2.0.11 10 | 11 | 12 | 13 | ## 共识协议 14 | 15 | ### 半同步网络模型 16 | 17 | - 正确性 18 | - 一致性 19 | - 可结束性 20 | 21 | n: 总人数 f:拜占庭节点 22 | 23 | n > 3f ,可以完成共识 => n>=3f+1 => n-f >= 2f+1 24 | 25 | CAP证明过程 26 | 27 | 通过聚合签名将签名信息压缩成一个签名信息，可以降低通信量。常见的聚合签名的库 28 | 29 | ### tendermint 协议 30 | 31 | pbft中收到的是2f+1节点，tendermint则是总投票权重2/3，并且基于p2p网络进行广播通信，并且存在round的概念，也就是说在一个高度失败了，会进行切换round并重试。 32 | 33 | - Prposer 离线 34 | - 区块不合法 35 | - 区块未及时广播 36 | - 未在有效的时间收集2/3的预投票 37 | - 未在有效时间收集2/3预提交 38 | 39 | 如果一直收集不到，实际就会不断地round，直到收集全，一旦收集全，就是最终一致性，不需要重组区块。 40 | 41 | #### lock-unlock 42 | 43 | lock： 44 | 45 | 当验证者对一个区块进行了预提交投票之后，则该验证者必须锁定在此区块上，也就意味着不管什么原因全网未共识，则在后续round的投票过程中必须投给自己当前锁定的区块。即使自己成为新的提案者，也必须提交该区块。**这是为了验证者在同一个区块高度对不同的区块进行预投票。** 46 | 47 | unlock： 48 | 49 | 验证者在看到一个具有更高轮数的polka时可以从自己当前锁定的区块解锁。从而避免死锁。 50 | 51 | #### validator轮换 52 | 53 | 被选中的概率与投票权重成正比，根据优先级选取（根据当前valset更新），若优先级相等，则根据地址最小选取。 54 | 55 | 需要满足： 56 | 57 | - 相同高度的valset 想通，且投票权重一致 58 | - 不同高度以上都是不同的 59 | - 概率与投票权重占比一致 60 | 61 | 轮换机制需要进一步确认✅ 62 | 63 | tendermint将当前区块的投票签名存储到下一个高度区块中，因为投票过程中当前区块内容是不允许发生变化的。 用lastCommit保存，结构如下： 64 | 65 | ```GO 66 | signature 67 | height 68 | round 69 | BlockID 70 | ``` 71 | 72 | Merkle树 ✅ 很多思想保存数据用到了，包括在做的公链改动，实际也是利用了其原理保存部分数据 73 | 74 | 需要对签名有个详细的理解✅ 75 | 76 | ### 双签举证 77 | 78 | 1个公钥对应两个投票，并且这个必须是放在区块中上链的。 79 | 80 | ## tendermint core 81 | 82 | ### 反应器 83 | 84 | 不同的消息处理实现不同的反应器 85 | 86 | 这一部分先大概得过了，后面回头再看✅ 87 | 88 | hook使用✅ （回调接口） 89 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/安全多方计算/同态加密.md: -------------------------------------------------------------------------------- 1 | 同态加密（homomorphic encryption）是一种特殊的加密技术，它可以在加密的状态下执行某些运算，而无需解密数据。具体来说，如果存在一个加密函数E，它可以将明文m加密为密文c，那么同态加密函数就是一个函数H，它可以在密文域上执行某些操作，生成一个新的密文，使得解密操作应用于该密文所得的结果等效于在明文域上执行相应的操作。 2 | 3 | 同态加密通常分为完全同态加密和部分同态加密两种类型。完全同态加密允许对密文进行任意的加法和乘法操作，而部分同态加密只允许对密文进行有限的加法或乘法操作。 4 | 5 | 同态加密的应用非常广泛，特别是在安全多方计算、隐私保护、云计算等领域有着广泛的应用。其主要原因是同态加密可以在不破坏数据隐私的情况下进行数据计算，使得数据处理更加高效和安全。 6 | 7 | 下面我将详细解释同态加密的原理和实现，以及其在安全多方计算中的应用。 8 | 9 | 一、同态加密的原理 10 | 11 | 1.1 基本概念 12 | 13 | 同态加密的基本思想是，将明文m加密为密文c后，对密文c进行一系列的运算，最终得到一个新的密文c'，使得解密操作应用于c'所得的结果等效于在明文域上执行相应的操作。 14 | 15 | 具体来说，设明文m、密文c和加密函数E满足以下条件： 16 | 17 | m是一个整数，且E(m)是整数m的一个密文。 18 | 19 | 加密函数E和解密函数D满足如下关系： 20 | 21 | D(E(m)) = m 22 | 23 | 对于两个密文c1和c2，定义c1+c2为它们在明文域上的和的密文。 24 | 25 | 对于两个密文c1和c2，定义c1*c2为它们在明文域上的积的密文。 26 | 27 | 对于一个密文c和一个整数n，定义nc为n乘以c的密文。 28 | 29 | 同态加密函数H的定义如下： 30 | 31 | 设c1和c2是两个密文，那么H(c1, c2) = c1 + c2 32 | 33 | 设c1和c2是两个密文，那么H(c1, c2) = c1 * c2 34 | 35 | 设c是一个密文，n是一个整数，那么H(c, n) = nc 36 | 37 | 同态加密函数H满足如下性质： 38 | 39 | 设m1和m2是两个明文，c1 = E(m1)，c2 = E(m2)，那么H(c1, c2) = E(m1 + m2) 40 | 41 | 设m1和m2是两个设m1和m2是两个整数，加密算法Enc_k(m)将明文m加密成密文c，其中k是密钥，即Enc_k(m) = c。同态加密算法能够满足以下性质： 42 | 43 | 1. 加法同态性质：对于加法操作m1 + m2，有Enc_k(m1 + m2) = Enc_k(m1) + Enc_k(m2)； 44 | 2. 乘法同态性质：对于乘法操作m1 × m2，有Enc_k(m1 × m2) = Enc_k(m1) × Enc_k(m2)； 45 | 3. 同态加密算法的安全性：即使攻击者拥有所有的密文，也不能从密文中推断出任何关于明文的信息。 46 | 47 | 基于这些性质，可以进行一些保护隐私的计算，例如在不暴露明文的情况下进行加法和乘法等计算。比如，如果想要计算两个人的年龄总和，但是不想暴露具体的年龄信息，就可以先用同态加密算法将年龄加密，然后在加密的状态下进行计算，最后再解密得到结果。 48 | 49 | 同态加密算法的实现有多种方式，例如基于离散对数问题的ElGamal加密、基于RSA问题的Paillier加密等。这些算法的实现都比较复杂，需要涉及到数论、模运算等数学知识，同时也需要考虑到实际应用中的性能和安全等方面的问题。因此，在实际使用时需要综合考虑多种因素，选择最合适的同态加密算法。 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/密码学中的数学/数论基础/数论_费马小定理.md: -------------------------------------------------------------------------------- 1 | 费马小定理（Fermat's Little Theorem）是数论中的一个重要定理，由法国数学家皮埃尔·德·费马（Pierre de Fermat）于17世纪提出。以下是费马小定理的陈述、证明和应用的详细解释： 2 | 3 | ## 费马小定理的陈述 4 | 5 | 对于任意整数a和素数p，如果a和p互质（即它们的最大公约数为1），那么满足以下关系： 6 | 7 | ``` 8 | a^(p-1) ≡ 1 (mod p) 9 | ``` 10 | 11 | 换句话说，a的p-1次方减去1后，结果可以被素数p整除。 12 | 13 | ## 费马小定理的证明 14 | 15 | 费马小定理的证明有多种方法，这里我们介绍一种基于乘法群的证明方法： 16 | 17 | 假设我们有一个模p下的乘法群，其中的元素为`{1, 2, ..., p-1}`。根据费马小定理的条件，整数a和素数p是互质的，所以a在模p下存在乘法逆元。我们将乘法群中的每个元素都乘以a，得到一个新的集合`{a, 2a, ..., (p-1)a}`。 18 | 19 | 注意，新集合中的元素在模p下两两不同余，因为如果存在两个不同的元素x和y使得`ax ≡ ay (mod p)`，则`a(x-y) ≡ 0 (mod p)`。由于a和p互质，我们可以得出`x ≡ y (mod p)`，这与x和y不同矛盾。 20 | 21 | 由于新集合与原始乘法群中的元素个数相同且在模p下两两不同余，那么新集合与原始乘法群实际上是相同的，只是元素的顺序发生了变化。因此，两个集合的乘积在模p下是相等的： 22 | 23 | ``` 24 | 1 * 2 * ... * (p-1) ≡ a * (2a) * ... * ((p-1)a) (mod p) 25 | ``` 26 | 27 | 我们可以在等式两边同时除以原始乘法群的乘积，得到： 28 | 29 | ``` 30 | a^(p-1) * (2^(p-1)) * ... * ((p-1)^(p-1)) ≡ 1 * 2 * ... * (p-1) (mod p) 31 | ``` 32 | 33 | 由于`2, 3, ..., p-1`都与p互质，它们在模p下都有乘法逆元。我们可以将等式两边分别乘以`2, 3, ..., p-1`的乘法逆元，得到： 34 | 35 | ``` 36 | a^(p-1) ≡ 1 (mod p) 37 | ``` 38 | 39 | ## 费马小定理应用 40 | 41 | 费马小定理在数论、密码学和计算机科学等领域具有广泛的应用，以下是一些主要应用： 42 | 43 | 1. **素性测试**：费马小定理是一种素性测试方法。对于一个大整数n，如果我们找到一个整数a满足费马小定理（即`a^(n-1) ≡ 1 (mod n)`），那么n可能是素数。然而，这种方法并非完全准确，因为存在一些合数（被称为费马伪素数）也满足费马小定理。因此，费马小定理常与其他素性测试方法结合使用，如米勒-拉宾测试。 44 | 2. **模运算的逆元**：费马小定理可以用来计算模运算的逆元。对于一个与素数p互质的整数a，它在模p下的逆元为`a^(p-2)`。这是因为根据费马小定理，我们有`a^(p-1) ≡ 1 (mod p)`。将等式两边都除以a，我们得到`a^(p-2) ≡ a^(-1) (mod p)`。 45 | 3. **加密算法**：费马小定理在加密算法中发挥着关键作用，如RSA加密算法和ElGamal加密算法等。这些算法的安全性基于模运算的性质以及费马小定理。 46 | 4. **编程竞赛和算法**：在编程竞赛和算法设计中，费马小定理常用于解决涉及素数和模运算的问题。通过应用费马小定理，我们可以在许多情况下优化算法，提高计算速度。 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/安全多方计算/基于seal的smpc协议.md: -------------------------------------------------------------------------------- 1 | ```mermaid 2 | sequenceDiagram 3 | participant P1 as 参与者1 4 | participant P2 as 参与者2 5 | participant P3 as 参与者3 6 | participant C as 计算节点 7 | 8 | P1->>+C: 密钥生成 9 | P2->>+C: 密钥生成 10 | P3->>+C: 密钥生成 11 | C-->>-P1: 公钥1 12 | C-->>-P2: 公钥2 13 | C-->>-P3: 公钥3 14 | 15 | P1->>+C: 密封输入1 16 | P2->>+C: 密封输入2 17 | P3->>+C: 密封输入3 18 | C-->>-P1: 密封消息1 19 | C-->>-P2: 密封消息2 20 | C-->>-P3: 密封消息3 21 | 22 | P1->>+C: 密封计算结果1 23 | P2->>+C: 密封计算结果2 24 | P3->>+C: 密封计算结果3 25 | C-->>-P1: 密封结果1 26 | C-->>-P2: 密封结果2 27 | C-->>-P3: 密封结果3 28 | 29 | P1->>+C: 密钥1解密结果 30 | P2->>+C: 密钥2解密结果 31 | P3->>+C: 密钥3解密结果 32 | C-->>-P1: 解密结果1 33 | C-->>-P2: 解密结果2 34 | C-->>-P3: 解密结果3 35 | 36 | P1->>+C: 合并解密结果 37 | P2->>+C: 合并解密结果 38 | P3->>+C: 合并解密结果 39 | C-->>-P1: 最终结果 40 | C-->>-P2: 最终结果 41 | C-->>-P3: 最终结果 42 | 43 | ``` 44 | 45 | 在这个流程图中，包括三个参与者和一个计算节点。其中，参与者1、2、3生成各自的公私钥对，并将公钥发送给计算节点。随后，参与者1、2、3将自己的输入进行密封，并发送给计算节点。计算节点对密封的输入进行计算，并将计算结果进行密封后发送给参与者1、2、3。参与者1、2、3对密封的计算结果进行解密，并将解密结果发送给计算节点。最后，计算节点将三个解密结果合并后输出最终结果。 46 | 47 | 48 | 49 | ## 应用 50 | 51 | 基于密封的安全多方计算协议在隐私保护和安全计算领域有很广泛的应用，以下是一些例子： 52 | 53 | 1. 选举投票：类似于我们之前实现的加密选举例子，可以使用基于密封的安全多方计算协议来保护选民的隐私，确保选举结果的准确性和公正性。 54 | 2. 数据隐私保护：在云计算和大数据分析中，数据隐私保护是一个很重要的问题。基于密封的安全多方计算协议可以让多个参与者在不泄露私密数据的前提下对数据进行计算、分析和共享。 55 | 3. 医疗数据共享：医疗数据隐私保护也是一个很重要的问题。基于密封的安全多方计算协议可以让多个医疗机构在不泄露病人隐私的前提下对医疗数据进行计算、分析和共享。 56 | 4. 联合学习：联合学习是一种在分布式设备上进行机器学习的方法，它可以用于保护参与者的隐私。基于密封的安全多方计算协议可以用于保护联合学习中的数据隐私和模型隐私。 57 | 5. 区块链隐私保护：区块链技术可以保证交易记录的公开和透明，但是交易参与者的隐私往往无法得到保护。基于密封的安全多方计算协议可以用于在区块链上进行隐私保护和安全计算。 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/密码学中的数学/代数基础/代数_域.md: -------------------------------------------------------------------------------- 1 | # 域的定义、性质和分类 2 | 3 | ## 定义 4 | 5 | 数学中，域是一种数学结构，它包括一个非空的集合和两个二元运算：加法和乘法，满足以下公理： 6 | - 加法和乘法都是封闭的（也就是说，对于任意的元素 $a$ 和 $b$，$a+b$ 和 $ab$ 仍然在域中）。 7 | - 加法和乘法都是可交换的（也就是说，对于任意的元素 $a$ 和 $b$，$a+b=b+a$ 和 $ab=ba$）。 8 | - 加法和乘法都是结合的（也就是说，对于任意的元素 $a$、$b$ 和 $c$，$a+(b+c)=(a+b)+c$ 和 $a(bc)=(ab)c$）。 9 | - 存在加法单位元 $0$ 和乘法单位元 $1$（也就是说，对于任意的元素 $a$，$a+0=a$ 和 $a*1=a$）。 10 | - 每个元素在加法和乘法下都有一个负元素和倒数元素。也就是说，对于任意的元素 $a$，存在一个元素 $-a$ 满足 $a+(-a)=0$，并且存在一个元素 $a^{-1}$ 满足 $aa^{-1}=1$。 11 | 12 | ## 性质 13 | 14 | 域的定义表明了它的一些重要的性质和特征，包括： 15 | - 在一个域中，两个不等于0的元素的乘积不可能等于0。 16 | - 域的元素个数是有限的，但它的大小可以是任意的。 17 | - 单位元是唯一的，但是一个元素可以有多个负元素和倒数元素。 18 | - 在一个有限域中，加法和乘法都是封闭的，并且存在一些元素的幂等，具有以下性质： 19 | - 它们的平方等于自身。 20 | - 所有的元素都可以表示成 $1$ 的幂的线性组合。 21 | 22 | ## 分类 23 | 24 | 域可以根据不同的属性进行分类。其中一些常见的分类包括： 25 | 26 | ### 代数域和超越域 27 | 28 | 代数域是指一个包含有理数的域，它的每个元素都可以表示为有理系数多项式的根。因此，代数域包含了所有的代数数。例如，实数和复数都是代数域。 29 | 30 | 超越域是指一个不包含有理数的域，它的所有元素都是超越数。例如，实函数域和复函数域都是超越域。 31 | 32 | ### 有限域和无限域 33 | 34 | 有限域是指一个元素数量有限的域。例如，有限域可以是 Z_p，其中所有的计算都是对模 $p$ 取余。无限域是指域的元素数量是无限的，例如实数域或复数域。 35 | 36 | ### 特征 37 | 38 | 一个域的特征指一个最小的正整数 $n$，使得 $n * 1 = 0$，如果不存在这样的数 $n$，则特征为0。域的特征是其一个重要的特征，它可以分为以下两类： 39 | - 特征为素数 $p$ 的域。例如，有限域 $Z_p$ 的特征为 $p$。这些域也被称为 Galois 域，因为它们的表示形式（即 Galois 字段）提供了一个继承的方式来构建有限域。 40 | - 特征为0的域，例如实数域。 41 | 42 | ### 子域 43 | 44 | 一个域的子集，如果它对相同的加法和乘法满足域公理，则它是该域的子域。例如，实数域的子域包括有理数域和所有代数数域。 45 | 46 | ### 扩张域 47 | 48 | 一个域 $E$ 是另一个域 $F$ 的扩张，如果 $F$ 是 $E$ 的子域。例如，复数域是实数域的扩张。扩张域是域论中一个重要的概念，它可以用于解决一系列基本的问题，如勒让德-格斯陶里定理和费马大定理等。 49 | 50 | ## 结论 51 | 52 | 因此，域是一个重要的数学结构，它包含了一个非空的集合和两个二元操作：加法和乘法。域的定义，性质和分类提供了一个清晰的框架来描述和理解域及其相关的概念。在数学和计算机科学中，域的研究是非常重要的，因为它在众多的应用中都扮演了不可替代的角色。这些应用依赖于域的数学结构和操作特性，如密码学，编码理论，算法设计等。 -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕libp2p网络之autoNAT.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## # 什么是Nats 4 | 5 | 当流量在网络边界之间移动时，很常见的一个过程是网络地址转换。网络地址转换（NAT）将**一个地址**从**一个地址空间**映射到**另一个地址空间**。 6 | 7 | **NAT允许多台计算机共享一个公共地址**，这对于IPv4协议的持续运行至关重要。否则，IPv4协议的32位地址空间将无法满足现代网络人口的需求。 8 | 9 | 例如，当我连接到家庭wifi时，我的计算机会得到一个IPv4地址10.0.1.15。这是为私有网络保留的IP地址范围之一。当我发起对公共IP地址的外部连接时，**路由器会将我的内部IP替换为它自己的公共IP地址**。**当数据从另一端回来时，路由器会再次将其转换回内部地址**。 10 | 11 | 虽然对于外发连接来说，NAT通常是透明的，但监听传入连接需要一些配置。**路由器只监听一个公共IP地址**，但内部网络中的任意数量的机器都可能处理请求。为了提供服务，您的**路由器必须被配置为将某些流量发送到特定的机器**，通常是通过**将一个或多个TCP或UDP端口从公共IP映射到内部IP**。 12 | 13 | 虽然手动配置路由器通常是可能的，但并不是每个想要运行点对点应用程序或其他网络服务的人都有这样的能力。 14 | 15 | 我们希望libp2p应用程序可以在任何地方运行，不仅仅限于数据中心或具有稳定公共IP地址的机器。为了实现这一点，以下是在libp2p中可用的NAT穿透的主要方法。 16 | 17 | ## 自动路由器配置 18 | 许多路由器支持自动配置协议进行端口转发，最常见的是UPnP或nat-pmp。 19 | 20 | 如果您的路由器支持这些协议之一，libp2p将**尝试自动配置一个端口映射**，以允许其监听传入流量。如果网络和libp2p实现支持，这通常是最简单的选择。 21 | 22 | ## 什么是AutoNAT？ 23 | AutoNAT允许节点请求其他节点拨打其所认为的公共地址。 24 | 25 | 对于位于NAT后面的私有节点，强烈建议: 26 | 27 | - 不要公布私有地址 28 | 29 | - 通过中继获得预订，以改善与公共网络的连接，并发布中继地址。 30 | 31 | 对于公共节点，建议： 32 | 33 | - 启动中继以协助其他节点 34 | - 考虑**激活DHT服务器模式**以改善与公共网络的连接。 35 | 如果大多数此类拨号尝试成功，则节点可以相当确定它没有在NAT后面。另一方面，如果大多数这些拨号尝试失败，则强烈表明NAT正在阻止传入连接。 36 | 37 | 要启动协议，节点向另一个节点发送一个Dial消息，其中包含多个地址列表。然后，节点使用与其常规libp2p连接不同的IP和节点ID尝试拨打这些地址。如果至少有一个拨号成功，则对方节点向请求节点发送一个带有ResponseStatus: SUCCESS的DialResponse消息。 38 | 39 | 如果所有拨号都失败，则对方节点将发送一个带有ResponseStatus: E_DIAL_ERROR的DialResponse消息。请求节点可以使用对等方的响应来确定它是否在NAT后面。 40 | 41 | 如果响应指示成功，则该节点很可能不在NAT后面，无需使用中继服务器来改善其连接。如果响应指示错误，则该节点很可能在NAT后面，可能需要使用中继服务器与网络中的其他节点进行通信。 42 | 43 | 为了防止某些类型的攻击，AutoNAT的libp2p实现不能拨打未基于请求节点的IP地址的任何多地址，并且不能通过中继连接接受拨号请求（因为不可能验证通过中继连接到达的节点的IP地址）。 44 | 45 | 这是为了防止放大攻击，在此攻击中，攻击者向许多客户端提供指向目标的相同的虚假映射地址，导致所有流量集中在目标上 46 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/op搭建避坑.md: -------------------------------------------------------------------------------- 1 | 1. 第二必须安装一致的node js 版本 2 | 2. 要加一个systemblock 啥玩意 3 | 3. 不知道官方文档为什么把pnpm 换成了yarn，变成yarn isntall 和yarnbuild ,我的linux 照样用ppm 4 | 4. https://learnblockchain.cn/question/3799 https://github.com/Qingquan-Li/blog/issues/131 ,解决mac 老是send requset 超时的问题，mac 默认终端不会被代理，需要设置下。 5 | 6 | 7 | 8 | ```go 9 | ## 10 | hash :0x6ff874e39a51c87799b068ac5bdf027cca565d27f539b01c1691b430be65c1b7 11 | number:1000 12 | timestamp:1691995518 13 | ``` 14 | 15 | 4. 有个json文件需要加systemConfigStartBlock，我写的就是上面的1000，有哥们说直接写0 16 | 5. direnv allow . 不起作用，直接source吧 17 | 18 | 19 | 20 | ## op-geth 启动 21 | 22 | ```shell 23 | ./build/bin/geth --datadir ./datadir --http --http.corsdomain="*" --http.vhosts="*" --http.addr=0.0.0.0 --http.api=web3,debug,eth,txpool,net,engine --ws --ws.addr=0.0.0.0 --ws.port=8888 --ws.origins="*" --ws.api=debug,eth,txpool,net,engine --syncmode=full --gcmode=archive --nodiscover --maxpeers=0 --networkid=42069 --authrpc.vhosts="*" --authrpc.addr=0.0.0.0 --authrpc.port=8551 --authrpc.jwtsecret=./jwt.txt --rollup.disabletxpoolgossip=true --password=./datadir/password --allow-insecure-unlock --mine --miner.etherbase=$SEQ_ADDR --unlock=$SEQ_ADDR 24 | ``` 25 | 26 | 27 | 28 | ## op-node 29 | 30 | ```shell 31 | ./bin/op-node \ 32 | --l2=http://localhost:8551 \ 33 | --l2.jwt-secret=./jwt.txt \ 34 | --sequencer.enabled \ 35 | --sequencer.l1-confs=3 \ 36 | --verifier.l1-confs=3 \ 37 | --rollup.config=./rollup.json \ 38 | --rpc.addr=0.0.0.0 \ 39 | --rpc.port=8547 \ 40 | --p2p.disable \ 41 | --rpc.enable-admin \ 42 | --p2p.sequencer.key=$SEQ_KEY \ 43 | --l1=$L1_RPC \ 44 | --l1.rpckind=$RPC_KIND 45 | ``` 46 | 47 | -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕Libp2p之circuit relay.md: -------------------------------------------------------------------------------- 1 | # circuit relay 是什么 2 | 3 | 电路继电器是一种传输协议，可通过第三方“中继”对等方在两个peer之间的流量路由。 4 | 5 | 在许多情况下，peers将无法以使他们公开访问的方式穿越其NAT和/或防火墙。或者他们可能不会共享可以直接交流的通用传输协议。 6 | 7 | 为了在NAT（例如NAT）等连接障碍物面前启用对等体系结构，Libp2p定义了一种称为P2P-Circuit的协议。当peer无法在公共地址上收听时，它可以拨打到relay peer，这将保持长期的连接。其他同行将能够使用P2P-circuit地址拨打relay peer，该地址将转发到其目的地。 8 | 9 | 中继协议的一个重要方面是它不是“透明的”。换句话说，源和目的地都知道流量正在被中继。这很有用，因为目的地可以看到用于打开连接的中继地址，并可能使用它来构造返回源的路径。它也不是匿名的——所有参与者都使用他们的对等ID进行识别，包括中继节点。 10 | 11 | ## 中继地址 12 | 13 | 中继电路是使用多地址识别的，该多地址包括其流量正**在被中继的对等体**（侦听对等体或“中继目标”）的对等体ID。 14 | 15 | 假设我有一个对等体ID为QmAlice。我想把我的地址发给我的朋友QmBob，但我的NAT不允许任何人直接拨我。 16 | 17 | 我能构造的最基本的p2p电路地址如下所示： 18 | 19 | ```markdown 20 | /p2p-circuit/p2p/QmAlice 21 | ``` 22 | 23 | 上面的地址很有趣，因为它不包括我们想要联系的对等点（QmAlice）或将传送流量的中继对等点的任何传输地址。如果没有这些信息，同伴给我打电话的唯一机会就是发现中继，并希望他们能与我建立联系。 24 | 25 | 一个更好的地址应该是/p2p/QmRelay/p2p-circuit/p2p/QmAlice。这包括特定中继对等体QmRelay的标识。如果对等方已经知道如何打开与QmRelay的连接，他们将能够联系到我们。 26 | 27 | 更好的做法是在地址中包含中继对等方的传输地址。比方说，我已经用对等ID QmRelay建立了到特定中继的连接。他们通过识别协议告诉我，他们正在侦听IPv4地址为198.51.100.0的55555端口上的TCP连接。我可以构建一个地址，描述通过该传输的特定中继到我的路径： 28 | 29 | ```markdown 30 | /ip4/198.51.100.0/tcp/55555/p2p/QmRelay/p2p-circuit/p2p/QmAlice 31 | ``` 32 | 33 | 在/p2p-circuit/上面之前的所有内容都是中继对等体的地址，其中包括传输地址和它们的对等体ID QmRelay。在/pp-circuit/之后是线路另一端我的对等端的对等端ID，QmAlice。 34 | 35 | 通过将完整的中继路径提供给我的朋友QmBob，他们能够快速建立中继连接，而不必“四处打听”有通往QmAlice的中继。 36 | 37 | ## 中继过程 38 | 39 | ![Circuit v2 Protocol Interaction](https://raw.githubusercontent.com/libp2p/specs/master/relay/circuit-v2.svg) 40 | 41 | 1. 节点A位于NAT和/或防火墙后面，例如通过AutoNAT服务检测到的。 42 | 43 | 2. 因此，节点A请求与中继器R进行预约。即，节点A要求中继器R代表其监听传入连接。 44 | 45 | 3. 节点B想要建立到节点a的连接。假设节点a不通告任何直接地址，而只通告中继地址，节点B连接到中继R，要求中继R中继到a的连接。 46 | 47 | 4. 中继R将连接请求转发到节点A，并最终中继A和B发送的所有数据 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/基础/非对称加密.md: -------------------------------------------------------------------------------- 1 | # 非对称加密 2 | 3 | 非对称加密，也称为公钥加密，是一种使用不同的密钥进行加密和解密的密码学技术。它通过引入一对密钥，即公钥和私钥，提供了更强大的安全性和便捷的密钥管理。以下是对非对称加密原理的详细介绍。 4 | 5 | ## 什么是非对称加密？ 6 | 7 | 在非对称加密中，**密钥分为两种：公钥和私钥。公钥用于加密数据，私钥用于解密数据。公钥是公开的，任何人都可以使用它来加密信息。私钥则需要保密，仅持有者可以解密由公钥加密的信息。同样，私钥也可以用于加密数据，然后使用公钥解密，这种方式常用于数字签名。** 8 | 9 | 非对称加密的优点在于解决了密钥分发问题，因为公钥可以公开传播，而无需担心安全性。然而，非对称加密的缺点是计算速度较慢，不适用于大量数据的加密。 10 | 11 | ## 非对称加密的应用场景 12 | 13 | 非对称加密的主要应用场景包括： 14 | 15 | 1. **安全通信**：通过公钥加密消息，确保只有私钥持有者能够解密。这样可以在不安全的通信环境中保护数据的机密性。 16 | 2. **数字签名**：使用私钥对消息生成签名，然后使用公钥进行验证。这样可以确保消息的完整性和来源。 17 | 3. **密钥交换**：非对称加密可以与对称加密结合使用，通过公钥加密对称密钥，实现安全地传输和共享对称密钥。 18 | 19 | ## 常见的非对称加密算法 20 | 21 | 以下是一些常见的非对称加密算法： 22 | 23 | - **RSA**：RSA是一种广泛使用的非对称加密算法，基于大数分解问题。RSA算法的安全性依赖于大数分解问题的计算难度。RSA支持加密、解密和数字签名等功能。 24 | 25 | - **ECC（Elliptic Curve Cryptography）**：ECC是一种基于椭圆曲线数学的非对称加密算法。相较于RSA，ECC在相同的安全级别下可以使用更短的密钥，从而降低计算和存储开销。ECC可以应用于加密、解密和数字签名等场景。 26 | 27 | - **ElGamal**：ElGamal是一种基于离散对数问题的非对称加密算法。与RSA类似，ElGamal算法的安全性依赖于离散对数问题的计算难度。ElGamal主要应 28 | 29 | - 用于加密和数字签名。 30 | 31 | - **DSA（Digital Signature Algorithm）**：DSA是一种基于离散对数问题的数字签名算法。与RSA相比，DSA仅支持数字签名，不支持加密和解密。DSA的一个变种是ECDSA（Elliptic Curve Digital Signature Algorithm），它将DSA与椭圆曲线密码学相结合，提供了更高的安全性和性能。 32 | - **Diffie-Hellman密钥交换**：Diffie-Hellman算法是一种基于离散对数问题的密钥交换协议。它允许通信双方在公开通道上交换信息，以生成共享密钥。虽然Diffie-Hellman本身不是加密算法，但它在非对称加密中发挥着关键作用，用于在不安全的通信环境中安全地交换对称密钥。 33 | 34 | ## 非对称加密的安全性与性能 35 | 36 | 非对称加密算法的安全性主要取决于其所基于的数学问题（如大数分解、离散对数等）的计算难度。随着密钥长度的增加，攻击者破解密钥的难度呈指数级增长。然而，增加密钥长度也会影响加密和解密的性能。 37 | 38 | 非对称加密算法通常比对称加密算法更慢，因为它们涉及到复杂的数学运算。在实际应用中，通常将非对称加密与对称加密结合使用，以实现更高的安全性和效率。例如，在TLS/SSL协议中，双方首先使用非对称加密算法（如RSA、ECC）交换对称密钥，然后使用对称加密算法（如AES）加密实际数据。 39 | 40 | 总之，非对称加密是一种强大且灵活的密码学技术，它通过使用一对密钥（公钥和私钥）解决了密钥分发问题，提供了数据加密、数字签名和密钥交换等功能。了解非对称加密的原理和常见算法，将有助于我们在实际应用中更好地利用加密技术来保护数据和通信安全。 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/基础/哈希函数.md: -------------------------------------------------------------------------------- 1 | # 哈希函数原理 2 | 3 | 哈希函数（Hash Function）是一种密码学算法，它**接受任意长度的输入并产生固定长度的输出**。哈希函数在计算机科学、密码学和数据存储等领域具有广泛的应用。以下是对哈希函数原理的详细介绍。 4 | 5 | ## 哈希函数的特性 6 | 7 | 理想的哈希函数应具备以下特性： 8 | 9 | 1. **确定性**：相同的输入必须产生相同的输出。这意味着每次使用相同的输入对哈希函数进行计算，都应该得到相同的哈希值。 10 | 2. **高速计算**：哈希函数应能快速地处理输入数据并生成哈希值。这使得哈希函数在数据检索、验证和密码学等场景中更加高效。 11 | 3. **雪崩效应**：哈希函数应对输入数据非常敏感，即使输入数据的微小变化也应导致哈希值的显著变化。这有助于确保哈希函数在密码学应用中的安全性。 12 | 4. **不可逆性**：从哈希值反推输入数据应该具有很高的计算难度。这意味着攻击者不能通过哈希值轻易地推导出原始数据，从而保护了数据的机密性。 13 | 5. **抗碰撞**：找到两个不同的输入，它们产生相同的哈希值，应具有很高的计算难度。这有助于防止哈希碰撞攻击，确保哈希函数在密码学应用中的安全性。 14 | 15 | ## 常见的哈希函数 16 | 17 | 以下是一些常见的哈希函数： 18 | 19 | - **MD5**：MD5（Message-Digest Algorithm 5）是一种广泛使用的哈希函数，由Ronald Rivest于1991年开发。MD5生成128位（16字节）的哈希值。然而，MD5的安全性已经受到质疑，因为存在多种有效的碰撞攻击方法。 20 | - **SHA-1**：SHA-1（Secure Hash Algorithm 1）是由美国国家安全局（NSA）开发的一种哈希函数。SHA-1生成160位（20字节）的哈希值。与MD5类似，SHA-1的安全性也受到质疑，已经被认为不再适用于密码学应用。 21 | - **SHA-2**：SHA-2是一种哈希函数族，包括SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224和SHA-512/256等变体。SHA-2是SHA-1的后继者，提供了更强大的安全性。SHA-2目前仍被认为是安全的 22 | - 并被广泛应用于各种密码学场景。 23 | - **SHA-3**：SHA-3是一种全新的哈希函数，由比尔吉·贝尔塔尔姆（Guido Bertoni）、琼·达门（Joan Daemen）、迈克尔·皮普（Michaël Peeters）和吉尔斯·范·奥斯特（Gilles Van Assche）于2012年开发。SHA-3基于Keccak算法，并在2015年被美国国家标准与技术研究所（NIST）采用为新的安全哈希算法标准。SHA-3包括SHA3-224、SHA3-256、SHA3-384、SHA3-512等变体。SHA-3的设计目标是提供与SHA-2相似的安全性，但具有不同的内部结构和抗攻击特性。 24 | 25 | ## 哈希函数的应用 26 | 27 | 哈希函数在计算机科学和密码学中具有广泛的应用，以下是一些常见的应用场景： 28 | 29 | 1. **数据完整性验证**：哈希函数可以用于验证数据的完整性。通过计算文件或数据的哈希值，并与预先存储的哈希值进行比较，可以检测数据是否被篡改。 30 | 2. **密码存储**：哈希函数通常用于安全地存储用户密码。将用户密码哈希后再存储，这样即使数据库泄露，攻击者也无法直接获取原始密码。通常，哈希函数与盐值（Salt）和密钥扩展函数（如PBKDF2、bcrypt、scrypt等）结合使用，以增强密码存储的安全性。 31 | 3. **数字签名**：哈希函数可以用于生成数字签名。通过对消息或文件的哈希值进行签名，可以确保数据的完整性和来源。常见的数字签名算法包括RSA、DSA和ECDSA等。 32 | 4. **区块链技术**：哈希函数在区块链技术中发挥着关键作用。区块链中的每个区块都包含上一个区块的哈希值，这样可以确保区块链的不可篡改性和数据完整性。此外，哈希函数还用于区块链的共识算法（如工作量证明，Proof of Work）中。 33 | 34 | 总之，哈希函数是一种重要的密码学技术，具有众多实际应用。了解哈希函数的原理和特性，有助于我们在数据完整性验证、密码存储、数字签名和区块链等场景中更好地利用哈希函数来保护数据安全。 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/密码学中的数学/代数基础/代数_指数对数.md: -------------------------------------------------------------------------------- 1 | # 详解四则运算、指数和对数运算 2 | 3 | ## 1. 四则运算 4 | 5 | 四则运算是数学中最基础的运算，包括加法、减法、乘法和除法，是我们在小学时就学习的基础知识。 6 | 7 | ### 1.1 加法 8 | 9 | 加法是将两个或多个数相加的运算。例如，2+3=5，其中2和3为加数，5为和。 10 | 11 | ### 1.2 减法 12 | 13 | 减法是将一个数从另一个数中减去的运算。例如，5-2=3，其中5为被减数，2为减数，3为差。 14 | 15 | ### 1.3 乘法 16 | 17 | 乘法是将两个或多个数相乘的运算。例如，2x3=6，其中2和3为因数，6为积。 18 | 19 | ### 1.4 除法 20 | 21 | 除法是将一个数分成相等的若干部分的运算。例如，6÷3=2，其中6为被除数，3为除数，2为商。 22 | 23 | ## 2. 指数运算 24 | 25 | 指数运算是数学中常见的一种运算，可以用来表示一个数被乘方的次数。例如，2的3次幂为$2^3$，表示为8。 26 | 27 | ### 2.1 指数的定义 28 | 29 | 指数的定义为：若a为非零实数，n为正整数，则a的n次幂为a相乘n次，即$a^n$ = a × a × ... × a（n个a），其中a为底数，n为幂。 30 | 31 | ### 2.2 指数运算的基本性质 32 | 33 | 指数运算具有以下基本性质： 34 | 35 | 1. $a^m×a^n$ = $a^{m+n}$，即同底数幂相乘，幂相加。 36 | 2. $\frac{a^m}{a^n}$ = $a^{m-n}$，即同底数幂相除，幂相减。 37 | 3. $(a^m)^n$ = $a^{mn}$，即幂的幂，底数不变，幂相乘。 38 | 4. $a^0$ = 1，（a ≠ 0），任何数的0次幂都等于1。 39 | 5. $a^{-n}$ = $\frac{1}{a^n}$，负指数的幂是分母为底数，分子为1的正指数幂。 40 | 6. $a^{\frac{1}{n}}$，则a的n次幂的n次方根为a的$\frac{}{}$ 41 | 42 | ### 2.3 指数运算的应用 43 | 44 | 指数运算在很多领域都有广泛的应用。例如： 45 | 46 | - 金融领域中，利率的计算就是基于指数运算的复合利率计算。 47 | - 在物理学中，指数运算可以用来表示指数增长和衰减的过程。 48 | - 在计算机科学中，指数运算经常出现在算法的设计中，如快速幂算法等。 49 | 50 | ## 3. 对数运算 51 | 52 | 对数运算是指用一个数来表示另一个数在某个数学问题中的指数的运算，它是指数运算的逆运算。 53 | 54 | ### 3.1 对数的定义 55 | 56 | 设$b>0$，且$b\neq$1，a>0，则称$y=log_ba$为以b为底a的对数。 57 | 58 | 这个定义中，b称为对数的底数，a称为对数的真数，y称为对数。例如，$log_24=x$，则2的x次幂等于4. 59 | 60 | ### 3.2 对数运算的基本性质 61 | 62 | 对数运算也具有一些基本性质： 63 | 64 | 1. $log_b(mn)$ = $log_bm$ + $log_bn$，即对数的积等于对数分别相加。 65 | 2. $log_b(\frac{m}{n})$ = $log_bm$ - $log_bn$，即对数的商等于对数分别相减。 66 | 3. $log_b(m^p)$ = $plog_bm$，即对数的幂等于幂对数乘以底数的对数。 67 | 4. $log_b1$ = 0，因为b的0次幂等于1。 68 | 5. $log_bb$ = 1，因为b的1次幂等于b。 69 | 6. $log_1b$ 不存在。 70 | 71 | ### 3.3 对数运算的应用 72 | 73 | 对数运算在很多领域中都有广泛的应用，例如： 74 | 75 | - 在声音和信号处理中，听觉上的响度和声音的分贝级别使用对数比率的概念。 76 | - 在化学中，pH值与酸碱性的浓度成比例，pH= $-log_{10}[H^+]$。 77 | - 在计算机科学中，对数运算经常使用在算法中，例如可排序算法和搜索算法。 78 | 79 | ## 结论 80 | 81 | 四则运算、指数和对数运算是数学中非常基础和重要的一些运算。它们在很多领域中都有广泛的应用，无论是在日常生活还是在学习和工作中都是必不可少的工具。 -------------------------------------------------------------------------------- /DApp_Development/主流链内置合约玩法.md: -------------------------------------------------------------------------------- 1 | ## bsc 2 | 3 | 创世合约里配置了系统合约，且地址是写死的，比如0x00000000000000001001, 会分配初始钱 4 | 5 | 然后会在第一个块进行初始化的调用。 6 | 7 | 8 | 9 | ### 使用案例 10 | 11 | a: 获取validator ，这个方式是通过eth api 调用，因为不需要网络通信延迟，所以很快 12 | 13 | ```GO 14 | method := "getValidators" 15 | 16 | // 指定的方法名和参数列表打包成一个 ABI 编码的字节数组 17 | data, err := p.validatorSetABIBeforeLuban.Pack(method) 18 | 19 | // 系统合约调用 20 | msgData := (hexutil.Bytes)(data) 21 | toAddress := common.HexToAddress(systemcontracts.ValidatorContract) 22 | gas := (hexutil.Uint64)(uint64(math.MaxUint64 / 2)) 23 | result, err := p.ethAPI.Call(ctx, ethapi.TransactionArgs{ 24 | Gas: &gas, 25 | To: &toAddress, 26 | Data: &msgData, 27 | }, blockNr, nil) 28 | 29 | // 将一个 ABI 编码的返回结果反序列化为含有具体类型数据的 Go 结构体（valSet） 30 | var valSet []common.Address 31 | err = p.validatorSetABIBeforeLuban.UnpackIntoInterface(&valSet, method, result) 32 | ``` 33 | 34 | b: 分配奖励 35 | 36 | 惩罚和分配奖励是由出块人来做的事情，也就是from是miner,to 是要调用的合约，在finalize阶段会创建，并且在其阶段就会处理完这个交易，直接通过callmsg来生成消息，然后通过applyTransaction底层操作。 37 | 38 | ```go 39 | // 生成系统交易 40 | method := "distributeFinalityReward" 41 | data, err := p.validatorSetABI.Pack(method, validators, weights) 42 | if err != nil { 43 | log.Error("Unable to pack tx for distributeFinalityReward", "error", err) 44 | return err 45 | } 46 | msg := p.getSystemMessage(header.Coinbase, common.HexToAddress(systemcontracts.ValidatorContract), data, common.Big0) 47 | return p.applyTransaction(msg, state, header, cx, txs, receipts, systemTxs, usedGas, mining) 48 | 49 | ``` 50 | 51 | ## quorum 52 | 53 | 54 | 55 | ## 预编译合约 56 | 57 | 以太坊的预编译合约不需要部署到以太坊上，因为它们已经作为区块链客户端（如 geth 或 OpenEthereum）的一部分实现。预编译合约主要用于处理复杂的计算，如加密哈希函数、椭圆曲线签名验证等，它们的地址是预先定义的，通常是较低的地址。 58 | 59 | 这些预编译合约的主要目的是提高某些计算密集型操作的性能。它们是在客户端的底层代码中实现的，而不是智能合约字节码。当 EVM 遇到一个预编译合约的地址时，它将直接调用相应的底层代码实现，而不是执行合约字节码。这样可以显著提高这些操作的执行速度。 60 | 61 | 原理： 62 | 63 | 生成的EVM指令中，Solidity编译器会将预编译合约`ecrecover`的地址（0x1）作为目标地址。接着，在EVM执行`STATICCALL`指令时，它会检查这个目标地址并发现它对应一个预编译合约，然后调用相应的底层实现 64 | 65 | ### 自定义预编译合约 66 | 67 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/密码学中的数学/代数基础/代数_集合关系映射.md: -------------------------------------------------------------------------------- 1 | # 集合、关系和映射 2 | 3 | ## 1. 集合 4 | 5 | 集合是数学中最基础的概念之一，是指由一些互不相同的元素组成的整体。例如，{1, 2, 3} 就是一个集合，其中1、2、3是集合的元素。 6 | 7 | ### 1.1 集合的定义 8 | 9 | 集合的定义为：一个集合是一些互不相同的数、元素或对象的集合体。一个元素要么属于一个集合，要么不属于一个集合。 10 | 11 | ### 1.2 集合的运算 12 | 13 | 集合有三种基本的运算： 14 | 15 | 1. 并集：包含两个或多个集合中的所有元素，重复的元素只被计算一次。例如，集合A={1, 2, 3}，集合B={3, 4, 5}，则它们的并集为A∪B={1, 2, 3, 4, 5}。 16 | 2. 交集：包含两个或多个集合中共有的元素。例如，集合A={1, 2, 3}，集合B={3, 4, 5}，则它们的交集为A∩B={3}。 17 | 3. 补集：包含一个集合中不属于另一个集合的元素。例如，集合A={1, 2, 3}，集合B={3, 4, 5}，则A的相对补集为A-B={1, 2}。 18 | 19 | ### 1.3 集合的性质 20 | 21 | 集合具有以下基本性质： 22 | 23 | 1. 任何集合都包含空集，即不包含任何元素的集合。 24 | 2. 如果两个集合包含的元素完全相同，则它们是相等的，即A=B。 25 | 3. 交换律：A∩B=B∩A。 26 | 4. 结合律：(A∩B)∩C=A∩(B∩C)和(A∪B)∪C=A∪(B∪C)。 27 | 5. 分配律：A∩(B∪C)=(A∩B)∪(A∩C)和A∪(B∩C)=(A∪B)∩(A∪C)。 28 | 6. 对于任何集合A，A∪A=A和A∩A=A。 29 | 30 | ## 2. 关系 31 | 32 | 关系用来描述两个或多个集合之间的联系，是数学中重要的概念。 33 | 34 | ### 2.1 关系的定义 35 | 36 | 关系是指一个集合中的元素与另一个集合中的元素之间的一种对应关系。例如，R是集合A与集合B之间的一个关系，可以表示为R(A,B)。 37 | 38 | ### 2.2 关系的运算 39 | 40 | 关系有三种基本的运算： 41 | 42 | 1. 复合关系：将两个关系作为输入，输出一个新的关系。 43 | 2. 逆关系：反转输入关系中的元素，输出一个新的关系。 44 | 3. 转换关系：改变关系的定义，输出一个新的关系。 45 | 46 | ### 2.3 关系的性质 47 | 48 | 关系具有以下基本性质： 49 | 50 | 1. 自反性：对于任何元素x，都有(x, x)∈R。 51 | 2. 对称性：如果(x, y)∈R，则(y, x)∈R。 52 | 3. 传递性：如果(x, y)∈R并且(y, z)∈R，则(x, z)∈R。 53 | 4. 反自反性：对于任何元素x，都有(x, x)∉R。 54 | 5. 反对称性：如果(x, y)∈R并且(y, x)∈R，则x=y。 55 | 56 | ## 3. 映射 57 | 58 | 映射是一种将一个对象与另一个对象联系起来的方式。在数学中，映射用来描述一个集合中的元素与另一个集合中的元素之间的一种对应关系。 59 | 60 | ### 3.1 映射的定义 61 | 62 | 映射是指一个集合中的元素与另一个集合中的元素之间的一种对应关系。其中，源集合中的元素称为定义域，目标集合中的元素称为值域，映射可以用一个函数来表示。 63 | 64 | ### 3.2 映射的性质 65 | 66 | 映射具有以下基本性质： 67 | 68 | 1. 反函数：如果f(x)=y，则f的反函数f-1(y)=x。 69 | 2. 满射：对于每一个y∈Y，都有一个x∈X，使得f(x)=y。 70 | 3. 单射：对于任意不同的x1、x2，有f(x1)≠f(x2)。 71 | 4. 双射：既满足满射，又满足单射。 72 | 73 | ### 3.3 应用 74 | 75 | 映射在很多领域中都有广泛的应用，例如： 76 | 77 | 1. 在计算机科学中，映射广泛应用于图形学，计算机视觉和人工智能等领域。 78 | 2. 在生物领域，映射用于描述基因之间的相互作用关系。 79 | 3. 在经济学中，映射被用来描述消费者需求弹性和产业投入产出关系等。 80 | 81 | ## 结论 82 | 83 | 集合、关系和映射是数学中非常基础和重要的概念，它们在很多领域中都有广泛的应用。对这些概念的深入理解，对于我们掌握数学的基础知识和高级概念都非常重要。 -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/tendermint/tendermint.md: -------------------------------------------------------------------------------- 1 | # What is Tendermint 2 | 3 | 组成： blockchain consensus engine + ABCI 接口 4 | 5 | - consensus engine : 确保在每台机器上以相同的顺序记录相同的事务 6 | - ABCI(Application Blockchain interface)：使交易能够用任何编程语言进行处理 7 | 8 | ## ABCI 9 | 10 | application做以下事情： 11 | 12 | - 维护数据库 13 | - 验证交易签名 14 | - 阻止双花 15 | 16 | ABCI通过3种消息协调tendermint core 和 上层应用程序。 17 | 18 | - **DeliverTx**：每个交易都必须通过DeliverTx消息进行传递。应用程序需要对接收到的每个带有DeliverTx消息的交易进行验证 19 | - **CheckTx**：CheckTx消息与DeliverTx类似，但仅用于验证事务。Tendermint Core的内存池首先使用CheckTx检查事务的有效性，并仅将有效事务中继到其对等端。例如，应用程序可以检查事务中递增的序列号，如果序列号旧，则在CheckTx时返回错误 20 | - **Commit**: commit hash 放在了下一个区块头（如何做到帮助捕获编程错误和简化轻量级客户端的开发？） 21 | 22 | 23 | >- `CheckTx` 阶段会在交易广播到 Tendermint 节点时立即执行，用于快速验证交易的基本属性，比如交易的格式、签名、交易费用等是否正确。在这个阶段，交易不会对应用程序状态做出任何更改，只是对交易的基本属性进行验证。 24 | >- `DeliverTx` 阶段会在交易被 Tendermint 打包成区块之后执行，用于对交易进行更加深入的验证，并将交易应用到应用程序状态中。在这个阶段，应用程序会检查交易是否符合应用程序协议和状态，并根据交易内容更新应用程序状态。 25 | 26 | 27 | 28 | 应用程序可以有多个 ABCI Socket 连接。Tendermint Core 会创建三个 ABCI 连接给应用程序：一个用于在 mempool 中广播交易时的验证，一个用于共识引擎运行区块提案，还有一个用于查询应用程序状态。 29 | 30 | ![image-20230516172751043](/Users/carver/Library/Application Support/typora-user-images/image-20230516172751043.png) 31 | 32 | ## Consensus Overview 33 | 34 | Tendermint是一个易于理解的、主要是异步的BFT共识协议。该协议遵循一个简单的状态机，看起来如下： 35 | 36 | ![image-20230516173116158](/Users/carver/Library/Application Support/typora-user-images/image-20230516173116158.png) 37 | 38 | ## technical nutshell 39 | 40 | Todo: 理一遍 41 | 42 | ![tx-flow](https://docs.tendermint.com/v0.34/assets/img/tm-transaction-flow.258ca020.png) 43 | 44 | ## tendermint stack 45 | 46 | ![cosmos-tendermint-stack](https://docs.tendermint.com/v0.34/assets/img/cosmos-tendermint-stack-4k.6aa56af6.jpg) 47 | 48 | ## tendermint core 49 | 50 | ### validator 51 | 52 | 成为validator : 53 | 54 | - genesis 55 | - ABCI 56 | 57 | ## 代码架构 58 | 59 | - reactor编程模型 60 | 61 | 62 | 63 | ```go 64 | git checkout master 65 | git tag -a v0.13.2 -m "upgrade to v0.13.2" 66 | git push --tags ## 之后git action会自动触发 67 | ``` 68 | 69 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/基础/数字签名.md: -------------------------------------------------------------------------------- 1 | # 数字签名原理 2 | 3 | 数字签名是一种用于验证数据完整性和身份认证的密码学技术。它允许发送者对数据进行签名，接收者可以验证签名以确保数据的完整性和发送者的身份。数字签名在网络安全、电子商务、电子邮件等场景中都有广泛应用。以下是对数字签名原理的详细介绍。 4 | 5 | ## 数字签名的基本过程 6 | 7 | 数字签名通常包括以下三个基本步骤： 8 | 9 | 1. **签名生成**：发送者对数据进行签名。首先，**对原始数据使用哈希函数生成哈希值**。然后，使用**发送者的私钥对哈希值进行加密，生成数字签名**。 10 | 2. **数据传输**：发送者将**原始数据和数字签名**一起发送给接收者。 11 | 3. **签名验证**：接收者验证数字签名。首先，使用发送者的公钥对数字签名进行解密，获取哈希值。然后，对收到的原始数据进行哈希计算，生成一个新的哈希值。最后，比较解密得到的哈希值与新计算的哈希值。如果两者相同，则签名验证成功，否则验证失败。 12 | 13 | ## 数字签名的安全性 14 | 15 | 数字签名的安全性主要依赖于以下几点： 16 | 17 | 1. **私钥的保密性**：只有发送者持有私钥，因此只有发送者才能生成有效的数字签名。私钥的保密性有助于确保签名的唯一性和不可伪造性。 18 | 2. **公钥的公开性**：公钥是公开的，任何人都可以使用它来验证数字签名。这有助于确保数字签名的可验证性。 19 | 3. **哈希函数的安全性**：哈希函数的安全性对数字签名的完整性验证至关重要。理想的哈希函数应具备不可逆性和抗碰撞特性，以防止攻击者伪造有效的签名。 20 | 4. **签名算法的安全性**：签名算法应具有足够的安全性，以防止攻击者通过破解算法来伪造或篡改签名。 21 | 22 | ## 常见的数字签名算法 23 | 24 | 以下是一些常见的数字签名算法： 25 | 26 | - **RSA**：RSA是一种基于大数分解问题的公钥密码学算法，支持数字签名。在RSA数字签名中，发送者使用私钥对数据哈希值进行加密，接收者使用公钥进行解密和验证。 27 | 28 | - **DSA**：DSA（Digital Signature Algorithm）是一种基于离散对数问题的数字签名算法。DSA是美国国家标准局（NIST）推荐的数字签名算法，通常与SHA系列哈希函数 29 | 30 | - 一起使用。DSA签名过程包括哈希值的计算、私钥签名和公钥验证。DSA相对于RSA在签名和验证速度上有优势，但生成签名的速度较慢。 31 | 32 | - **ECDSA**：ECDSA（Elliptic Curve Digital Signature Algorithm）是一种基于椭圆曲线密码学的数字签名算法。ECDSA具有更短的密钥长度和更高的安全性，相比于RSA和DSA在计算效率和存储空间上有优势。ECDSA广泛应用于加密货币（如比特币）和安全通信协议（如TLS）中。 33 | - **EdDSA**：EdDSA（Edwards-curve Digital Signature Algorithm）是另一种基于椭圆曲线密码学的数字签名算法，与ECDSA类似。EdDSA使用特殊的Edwards曲线，提供了较高的性能和安全性。常见的EdDSA变体包括Ed25519和Ed448。 34 | 35 | ## 数字签名的应用 36 | 37 | 数字签名在多种场景中都发挥着关键作用，以下是一些常见的应用： 38 | 39 | 1. **安全通信**：数字签名用于保障通信双方的身份真实性和数据完整性。例如，在安全套接字层（SSL）/传输层安全（TLS）协议中，数字签名用于验证服务器和客户端的证书，确保通信过程中的安全性。 40 | 2. **电子邮件安全**：数字签名用于验证电子邮件的发送者身份和内容完整性。常见的电子邮件签名标准包括PGP（Pretty Good Privacy）和S/MIME（Secure/Multipurpose Internet Mail Extensions）。 41 | 3. **软件安全**：数字签名用于验证软件包的完整性和来源。开发者可以对软件包进行签名，用户在下载和安装软件时可以验证签名，确保软件没有被篡改或伪造。 42 | 4. **加密货币**：在加密货币（如比特币）系统中，数字签名用于验证交易的有效性和用户身份。用户使用私钥对交易进行签名，其他用户可以使用公钥验证签名，确保交易的安全性和不可篡改性。 43 | 44 | 总之，数字签名是一种重要的密码学技术，为数据完整性和身份验证提供了可靠的保障。了解数字签名的原理和应用，有助于我们在实际场景中更好地利用数字签名技术来确保数据安全。 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/签名/bls签名.md: -------------------------------------------------------------------------------- 1 | BLS签名是一种新兴的数字签名机制，它的快速性和高效性使得它在密码学领域中备受关注。BLS签名采用的是椭圆曲线上的群运算，具有优异的性能，其安全程度也得到了大规模的证明。下面我们将详细介绍BLS签名的原理、安全性、应用等方面内容。 2 | 3 | ## 1. BLS签名原理 4 | 5 | ### 1.1 椭圆曲线密码学（ECC） 6 | 7 | 椭圆曲线加密系统通过椭圆曲线上的离散对数问题来构建公钥密码系统，可以提供与RSA类似的保密性、非否认性和完整性。相比于RSA，ECC算法具有更小的密钥尺寸和更快的速度，并且在某些情况下可以提供更高的安全性。 8 | 9 | ### 1.2 群论 10 | 11 | 在密码学中，群论是一种抽象的代数结构，可用于描述各种数学对象的对称性。群包含一个集合和一个二元运算符“乘法”，并满足以下四个条件：封闭性、结合律、恒等元素和逆元素。一个群被称为Abelian群，如果它的运算符是可交换的。 12 | 13 | ### 1.3 BLS签名机制 14 | 15 | BLS签名机制的核心思想是利用椭圆曲线上的双线性对构建签名方案。这里我们简单介绍一下相关的数学符号和术语： 16 | 17 | - G：表示椭圆曲线上的固定生成点。 18 | - n：表示G的阶，即一个满足nG=0的整数n。 19 | - 群运算：加法运算以及标量乘法运算（即kP=P+P+...+P，其中k为整数）。 20 | - 双线性对：一个映射e:G×G→GT，满足以下性质： 21 | 1. 双线性性：对于任意的x,y∈Zn*和P,Q∈G，有e(xP,yQ)=e(P,Q)xy。 22 | 2. 非退化性：存在P∈G，使得e(P,P)!=1。 23 | 3. 可计算性：可以在多项式时间内计算出e(P,Q)的值。 24 | 25 | BLS签名机制包含三个主要阶段：密钥生成、签名和验证。 26 | 27 | #### 1.3.1 密钥生成 28 | 29 | BLS签名机制中的密钥由一个公钥P和一个私钥s组成，其中P=sG。私钥s为一个随机整数，通常取值范围是[1,n-1]；而公钥P是将生成点G乘以随机数s得到的点。 30 | 31 | #### 1.3.2 签名 32 | 33 | BLS签名机制中的签名是一个单个元素，通常表示为sigma。签名者通过将消息m和私钥s结合在一起生成BLS签名。具体地，签名过程如下： 34 | 35 | 1. 将消息哈希成椭圆曲线上的点H(m)； 36 | 2. 计算签名sigma=sH(m)，其中s为私钥，H(m)为哈希后得到的点； 37 | 3. 返回签名sigma。 38 | 39 | #### 1.3.3 验证 40 | 41 | BLS签名机制中的验证需要以下信息：公钥P、消息m和签名sigma。验证者通过检查是否满足以下条件来验证签名的有效性： 42 | 43 | e(sigma,G)=e(H(m),P) 44 | 45 | 如果等式成立，则签名有效；否则，签名无效。 46 | 47 | ### 1.4 BLS签名的优缺点 48 | 49 | BLS签名的主要优点包括快速性、高效性和强安全性。由于使用了椭圆曲线上的群环结构，因此可以利用已有的密码学方法进行分析，从而证明其安全性。 50 | 51 | 此外，BLS签名的密钥尺寸相对较小，速度快，适合于资源受限的设备。 52 | 53 | BLS签名的缺点在于其复杂度较高，需要进行多次群运算和双线性对的计算，因此对于某些应用场景来说不太适合。 54 | 55 | ## 2. BLS签名安全性分析 56 | 57 | BLS签名的安全性基于双线性对的离散对数难题。具体地说，如果攻击者可以有效地计算出椭圆曲线上的群元素的离散对数，则可以破解该密码学方案。但是，在目前的技术水平下，这个问题是极其困难的。 58 | 59 | 此外，BLS签名机制还具有强保密性和非否认性。任何人都无法获取到私钥s，因此只有拥有私钥的人才能够生成有效的签名。 60 | 61 | ## 3. BLS签名应用 62 | 63 | BLS签名机制已经在各种区块链项目中得到了广泛的应用。例如，BLS签名已经被用于Zcash、Filecoin等项目中。以Zcash为例，其匿名交易过程需要使用BLS签名来保证交易的可靠性和隐私性。 64 | 65 | 此外，BLS签名也可以用于构建去中心化身份验证系统、多方计算等领域。相信未来BLS签名会在更多的应用场景中得到广泛应用。 66 | 67 | ## 4. 总结 68 | 69 | BLS签名是一种新兴的数字签名机制，它采用了椭圆曲线上的群环结构和双线性对，具有快速、高效和强安全性的优点。BLS签名已经被广泛应用于区块链项目中，未来将在更多领域得到应用。 -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/cosmos/tendermint/tendermint源码架构.md: -------------------------------------------------------------------------------- 1 | consensus 2 | 3 | OnStart -> timeoutRoutine start 超时处理 4 | 5 | ​ -> go cs.receiveRoutine(0) 开启接收协程 6 | 7 | 8 | 9 | 10 | 11 | ## cs.receiveRoutine 12 | ```GO 13 | for { 14 | select { 15 | case <-cs.txNotifier.TxsAvailable(): 16 | cs.handleTxsAvailable() 17 | 18 | case mi = <-cs.peerMsgQueue: 19 | if err := cs.wal.Write(mi); err != nil { 20 | cs.Logger.Error("failed writing to WAL", "err", err) 21 | } 22 | 23 | // handles proposals, block parts, votes 24 | // may generate internal events (votes, complete proposals, 2/3 majorities) 25 | cs.handleMsg(mi) 26 | 27 | case mi = <-cs.internalMsgQueue: 28 | err := cs.wal.WriteSync(mi) // NOTE: fsync 29 | if err != nil { 30 | panic(fmt.Sprintf( 31 | "failed to write %v msg to consensus WAL due to %v; check your file system and restart the node", 32 | mi, err, 33 | )) 34 | } 35 | ... 36 | // handles proposals, block parts, votes 37 | cs.handleMsg(mi) 38 | 39 | case ti := <-cs.timeoutTicker.Chan(): // tockChan: 40 | if err := cs.wal.Write(ti); err != nil { 41 | cs.Logger.Error("failed writing to WAL", "err", err) 42 | } 43 | 44 | // if the timeout is relevant to the rs 45 | // go to the next step 46 | cs.handleTimeout(ti, rs) 47 | } 48 | } 49 | ``` 50 | 51 | 一共做3件事： 52 | 53 | - 处理外部接收的消息 54 | - 处理内部接收的消息 55 | - 处理超时消息 56 | 57 | 58 | 59 | ## 共识流程 60 | 61 | ```markdown 62 | (谁，在什么时候做) createProposalBlock -> 63 | 64 | ​ -> （从交易池中获取交易） blockExec.mempool.ReapMaxBytesMaxGas(maxDataBytes, maxGas) 65 | 66 | ​ -> 组装区块（构建基本区块，使用状态数据填充） 67 | 68 | 69 | 70 | createProposalBlock -> NewProposal(根据上面区块以及高度round)->SignProposal-> SetProposalAndBlock (ProposalMessage和BlockPartMessage （如何处理）)->signVote(对区块投票,塞入VoteMessage消息)-> 71 | ``` 72 | 73 | 74 | 75 | ## 编程技巧 76 | 77 | - 对于一个通知通道，为什么还要用接口封装 78 | 79 | ```go 80 | type txNotifier interface { 81 | TxsAvailable() <-chan struct{} 82 | } 83 | 84 | ``` 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/死磕optimism之batch提交.md: -------------------------------------------------------------------------------- 1 | ```GO 2 | case <-ticker.C: 3 | if err := l.loadBlocksIntoState(l.shutdownCtx); errors.Is(err, ErrReorg) { 4 | err := l.state.Close() 5 | if err != nil { 6 | l.log.Error("error closing the channel manager to handle a L2 reorg", "err", err) 7 | } 8 | l.publishStateToL1(queue, receiptsCh, true) 9 | l.state.Clear() 10 | continue 11 | } 12 | l.publishStateToL1(queue, receiptsCh, false) 13 | ``` 14 | 15 | 这段代码将所有l2区块加载到channelManager中，这是个通道管理器，然后再将其切成帧发布到L1 16 | 17 | 18 | 19 | ```go 20 | // publishTxToL1 submits a single state tx to the L1 21 | func (l *BatchSubmitter) publishTxToL1(ctx context.Context, queue *txmgr.Queue[txData], receiptsCh chan txmgr.TxReceipt[txData]) error { 22 | // send all available transactions 23 | l1tip, err := l.l1Tip(ctx) 24 | if err != nil { 25 | l.log.Error("Failed to query L1 tip", "error", err) 26 | return err 27 | } 28 | l.recordL1Tip(l1tip) 29 | 30 | // Collect next transaction data 31 | txdata, err := l.state.TxData(l1tip.ID()) 32 | if err == io.EOF { 33 | l.log.Trace("no transaction data available") 34 | return err 35 | } else if err != nil { 36 | l.log.Error("unable to get tx data", "err", err) 37 | return err 38 | } 39 | 40 | l.sendTransaction(txdata, queue, receiptsCh) 41 | return nil 42 | } 43 | ``` 44 | 45 | ```GO 46 | func (l *BatchSubmitter) sendTransaction(txdata txData, queue *txmgr.Queue[txData], receiptsCh chan txmgr.TxReceipt[txData]) { 47 | // Do the gas estimation offline. A value of 0 will cause the [txmgr] to estimate the gas limit. 48 | data := txdata.Bytes() 49 | intrinsicGas, err := core.IntrinsicGas(data, nil, false, true, true, false) 50 | if err != nil { 51 | l.log.Error("Failed to calculate intrinsic gas", "error", err) 52 | return 53 | } 54 | 55 | candidate := txmgr.TxCandidate{ 56 | To: &l.Rollup.BatchInboxAddress, // 常规的EOA地址 57 | TxData: data, 58 | GasLimit: intrinsicGas, 59 | } 60 | queue.Send(txdata, candidate, receiptsCh) 61 | } 62 | ``` 63 | 64 | 最终op-batcher根据L1Id 将相关的交易全部提交到了BatchInboxAddress 65 | -------------------------------------------------------------------------------- /DApp_Development/合约基础/solidity_create2.md: -------------------------------------------------------------------------------- 1 | # 使用CREATE2部署智能合约 2 | 3 | ## 简介 4 | 5 | CREATE2 是 Ethereum EVM 中的一种操作码，用于部署智能合约。与 CREATE 操作码不同，CREATE2 的独特之处在于它允许在部署合约之前预测合约地址。这种特性为开发者提供了新的部署方法和更多的灵活性，特别是在需要预测合约地址的场景下。 6 | 7 | ## 创建合约地址的原理 8 | 9 | 在 Ethereum 中，合约地址是通过部署者地址和该地址的随机数（`nonce`）计算得出的。CREATE2 改变了这种计算方式，通过部署者地址、一个盐值（`salt`）和合约的字节码进行计算。这意味着，只要部署者、盐值和字节码不变，合约地址将始终相同。 10 | 11 | 计算公式如下： 12 | 13 | ``` 14 | keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:] 15 | ``` 16 | 17 | ## 使用案例 18 | 19 | ### 1. 预测合约地址 20 | 21 | 由于 CREATE2 计算合约地址的方式，它可以让开发者在部署合约之前知道合约地址。这种特性对于某些去中心化应用（如闪电网络和状态通道）非常有用。 22 | 23 | ### 2. 惰性部署 24 | 25 | 开发者可以在需要时才部署合约，而在此之前，他们可以预先告知用户合约的地址。这样一来，用户可以在合约实际部署之前与其交互，从而节省部署成本。 26 | 27 | ### 3. 代理合约模式 28 | 29 | 在某些场景下，开发者可能希望部署多个功能相似的合约。使用 CREATE2 可以创建一个固定地址的代理合约，从而使得所有相关合约共享相同的接口。 30 | 31 | ## 如何使用 CREATE2 32 | 33 | 以下是一个使用 Solidity 实现的简单示例，演示了如何使用 CREATE2 部署合约。 34 | 35 | ```solidity 36 | pragma solidity ^0.8.0; 37 | 38 | contract DeployedContract { 39 | uint256 public value; 40 | 41 | constructor(uint256 _value) { 42 | value = _value; 43 | } 44 | } 45 | 46 | contract Factory { 47 | function deploy(uint256 _value, bytes32 _salt) public { 48 | bytes memory bytecode = type(DeployedContract).creationCode; 49 | bytes32 bytecodeHash = keccak256(abi.encodePacked(bytecode, _value)); 50 | 51 | address addr; 52 | assembly { 53 | addr := create2(0, add(bytecode, 32), mload(bytecode), _salt) 54 | } 55 | 56 | require(addr != address(0), "Failed to deploy contract"); 57 | } 58 | 59 | function predictAddress(uint256 _value, bytes32 _salt) public view returns (address) { 60 | bytes memory bytecode = type(DeployedContract).creationCode; 61 | bytes32 bytecodeHash = keccak256(abi.encodePacked(bytecode, _value)); 62 | 63 | return address(uint160(uint256(keccak256(abi.encodePacked( 64 | byte(0xff), 65 | address(this), 66 | _salt, 67 | bytecodeHash 68 | ))))); 69 | } 70 | } 71 | 72 | ``` 73 | 74 | 75 | 76 | ## 场景 77 | 78 | ### 灵活部署合约 79 | 80 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/密码学中的数学/代数基础/代数_多项式.md: -------------------------------------------------------------------------------- 1 | # 多项式及其运算 2 | 3 | ## 一、多项式的定义 4 | 5 | 多项式（Polynomial）是由一系列变量和常量以及它们之间的加、减和乘法运算构成的表达式。例如，$x^2+3x−5$ 就是一个二次多项式。多项式的变量通常用字母表示，常数可以是实数、有理数、复数等。 6 | 7 | 一个多项式一般可以表示为：$$ P(x)=a_nx^n+a_{n-1}x^{n-1}+...+a_2x^2+a_1x^1+a_0 $$ 8 | 9 | 其中，$a_i$ 为常数系数，$x$ 为变量，$n$ 为多项式的次数（最高次项的指数）。多项式次数为 $n$，则叫做 $n$ 次多项式，其中，$a_n$ 不等于 $0$。 10 | 11 | ## 二、多项式的运算 12 | 13 | 多项式有加法、减法、乘法、除法和取模等基本运算。 14 | 15 | ### 1. 加法和减法 16 | 17 | 两个多项式的加法定义为把相同项的系数相加起来，不同项保留原来的系数。例如，给定两个多项式 $P(x) = 2x^2 + 5x + 3$ 和 $Q(x) = 3x^2 + 2x + 7$，则它们的和为 $P(x)+Q(x) = (2+3)x^2 +(5+2)x +(3+7) = 5x^2 + 7x + 10$，差为 $P(x)-Q(x) = -x^2 +3x -4$。 18 | 19 | ### 2. 乘法 20 | 21 | 两个多项式的乘法定义为把两个多项式中的每一项相乘，然后将相同项的幂次的系数相加。例如，给定两个多项式 $P(x) = 2x^2 + 3x + 4$ 和 $Q(x) = x^3 + 5x^2 + 6$，则它们的积为 $P(x)Q(x) = (2x^2 + 3x + 4)(x^3 +5x^2 +6)$，展开得到：$$\begin{aligned} P(x)Q(x) &= 2x^5 + 13x^4 + 32x^3 + 39x^2 + 18x + 24 \end{aligned}$$ 22 | 23 | ### 3. 除法 24 | 25 | 多项式除法是指用除数 $D(x)$ 去除被除数 $N(x)$。通过 Polynomial Long Division 算法进行多项式除法。对于多项式 $N(x)$，存在唯一两个多项式 $D(x)、R(x)$，使得$N(x)=D(x)Q(x)+R(x)$，且 $R(x)$ 的次数小于 $D(x)$ 的次数。 26 | 27 | ### 4. 取模 28 | 29 | 多项式模运算是指除法后的余数。例如，给定两个多项式 $N(x)$ 和 $D(x)$，则 $N(x)$ 对 $D(x)$ 取模的结果为 $N(x)$ 除以 $D(x)$ 的余数。 30 | 31 | ## 三、多项式的重要定理 32 | 33 | ### 1. 余数定理 34 | 35 | 多项式 $P(x)$ 除以 $(x-a)$ 的余数为 $P(a)$。证明如下： 36 | 37 | 我们将 $P(x)$ 可以表示为 $(x-a)Q(x)+R$，其中 $R$ 为余数，同时满足 $0 \le \operatorname{deg}(R) < 1$。又有$P(a) = (a-a)Q(a) + R = R$，因为 $(a-a)=0$。 38 | 39 | ### 2. 因式定理 40 | 41 | 如果 $a$ 是多项式 $P(x)$ 的一个根，即 $P(a)=0$，则 $P(x)$ 可以表示为 $(x-a)Q(x)$ 的形式。证明如下： 42 | 43 | 根据余数定理 $P(x) = (x-a)Q(x) + R$，其中 $R=P(a)$，如果 $P(a)=0$，则 $R=0$。因此，$P(x) = (x-a)Q(x)$。 44 | 45 | ### 3. 中间值定理 46 | 47 | 中间值定理用于证明一个多项式在两个实数之间至少存在一个实根。具体地说，如果 $P(x)$ 是一个次数为 $n$ 的多项式，$a 本文研究了可验证随机函数（Verifiable Random Functions，简称VRF）的原理、实现和应用场景。VRF是一种密码学概念，将密码学签名和伪随机函数相结合，提供了一种可验证的随机性。 4 | 5 | **关键词：** VRF、可验证随机函数、密码学、伪随机函数、签名 6 | 7 | ## 引言 8 | 9 | 在密码学领域，随机性是一个关键要素。许多密码学原语，如密钥生成、加密和签名，都依赖于随机数。然而，在某些应用场景中，仅仅生成随机数并不足够。在这些场景中，需要能够验证随机数的生成过程是公平和无偏的。这就是可验证随机函数（VRF）的概念应运而生。 10 | 11 | VRF是一种将密码学签名和伪随机函数相结合的技术，它可以生成随机数的同时生成一个证明，证明这个随机数是公平且无偏的。这使得VRF在区块链、密码学投票系统等领域具有广泛的应用价值。 12 | 13 | ## VRF基本原理 14 | 15 | VRF是一种特殊的伪随机函数，它有以下三个特性： 16 | 17 | 1. **唯一性**：对于相同的输入，VRF的输出是唯一的。 18 | 2. **不可预测性**：在不知道密钥的情况下，VRF的输出是不可预测的。 19 | 3. **可验证性**：VRF的计算过程可以生成一个证明，该证明可以证明输出是由正确的密钥生成的，且没有偏差。 20 | 21 | VRF的工作原理可以分为以下几个步骤： 22 | 23 | 1. **密钥生成**：生成一对密钥，包括公钥（PK）和私钥（SK）。公钥用于验证随机数的正确性，私钥用于生成随机数。 24 | 2. **计算VRF**：使用私钥（SK）和输入（x）计算VRF值（y）和证明（π）。具体计算方法取决于所使用的VRF方案。 25 | 3. **验证**：使用公钥（PK）、输入（x）、VRF值（y）和证明（π）进行验证。如果验证通过，则说明VRF值是公平且无偏的。 26 | 27 | ## VRF实现方法 28 | 29 | ### 基于离散对数问题的VRF 30 | 31 | 离散对数问题是密码学中一个经典的难题。基于离散对数问题的VRF使用了一种特殊的签名方案，如Schnorr签名或BLS签名。这类VRF的安全性依赖于离散对数问题的难解性。 32 | 33 | ### 基于椭圆曲线密码学的VRF 34 | 35 | 椭圆曲线密码学（ECC）是一种基于椭圆曲线数学的密码学方法。ECC具有较短的密钥长度和较高的安全性，因此在现代密码学应用中非常流行。基于ECC的VRF使用椭圆曲线上的点作为公钥和私钥，通过特定的椭圆曲线运算来计算VRF值和证明。 36 | 37 | ### 基于lattice的VRF 38 | 39 | lattice（格）密码学是一种基于格数学的密码学方法。与其他密码学方法相比，lattice密码学在量子计算机攻击面前具有更高的安全性。基于lattice的VRF使用格上的向量作为密钥，通过复杂的格运算来实现VRF的计算和验证。 40 | 41 | ## VRF应用场景 42 | 43 | ### 区块链共识算法 44 | 45 | 在区块链领域，共识算法是用于解决去中心化网络中的信任问题的关键技术。VRF可以用于实现公平且去中心化的共识算法，如Algorand和Ouroboros等。通过使用VRF，可以确保参与者在区块链网络中的角色分配是公平且随机的。 46 | 47 | ### 密码学投票系统 48 | 49 | 在密码学投票系统中，为了确保投票过程的公平性和隐私性，可以使用VRF生成随机数作为加密投票的随机噪声。通过VRF证明，可以确保投票过程中随机噪声的生成是公平且无偏的，从而保证投票结果的真实性和可信度。 50 | 51 | ### 隐私保护数据共享 52 | 53 | 在数据共享场景中，为了保护用户隐私，可以使用VRF生成随机噪声对原始数据进行加密。通过这种方式，即使数据泄露，攻击者也无法从加密数据中还原出原始数据。同时，由于VRF的可验证性，数据接收方可以确保数据共享过程中的随机噪声生成是公平且无偏的，从而确保数据的真实性和可信度。 54 | 55 | ## VRF的安全性 56 | 57 | VRF的安全性主要取决于所使用的密码学方法和难解性假设。常见的安全性标准包括： 58 | 59 | 1. **计算不可区分性**：在不知道私钥的情况下，攻击者无法区分VRF的输出与随机数。 60 | 2. **唯一性**：对于同一输入，VRF的输出是唯一的。这可以防止攻击者生成多个有效证明来欺骗验证者。 61 | 3. **可验证性**：验证者可以使用公钥快速验证VRF的证明，确保输出的随机数是公平且无偏的。 62 | 63 | 为了满足这些安全性要求，VRF实现方案需要经过严格的密码学分析和安全性证明。 64 | 65 | ## 总结 66 | 67 | VRF是一种密码学概念，将密码学签名和伪随机函数相结合，为随机数生成提供可验证性。VRF在区块链、密码学投票系统、隐私保护数据共享等领域具有广泛的应用价值。VRF的实现方法包括基于离散对数问题的VRF、基于椭圆曲线密码学的VRF和基于lattice的VRF等。为了保证VRF的安全性，实现方案需要经过严格的密码学分析和安全性证明。 68 | -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕libp2p之Peer.md: -------------------------------------------------------------------------------- 1 | ## Peer ID 2 | 3 | 对等体标识（通常写为PeerID）是对整个对等网络中特定对等体的**唯一引用**。 4 | 5 | 除了作为每个对等体的唯一标识符外，**对等体ID也是对等体与其公共密钥之间的可验证链接**。 6 | 7 | 每个libp2p对等端都控制一个私钥，对所有其他对等端保密。每个私钥都有一个相应的公钥，并与其他对等方共享。 8 | 9 | 公钥和私钥（或“密钥对”）一起允许对等方建立彼此之间的安全通信信道。 10 | 11 | 从概念上讲，**对等体ID是对等体公钥的加密哈希**。当对等方建立安全通道时，散列可以用于验证用于保护通道的公钥是否与用于识别对等方的公钥相同。 12 | 13 | [Peer ID规范](https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md)详细介绍了用于libp2p公钥的字节格式，以及如何对密钥进行散列以生成有效的Peer ID。 14 | 15 | 16 | 17 | ## 对等 ID 如何表示为字符串 18 | 19 | 对等Id是多散列，它被定义为一种紧凑的二进制格式。 20 | 21 | 使用比特币使用的相同字母表，将多哈希编码到base58是很常见的。 22 | 23 | 以下是对等ID的一个示例，表示为base58编码的多散列：QmYyQSo1c1Ym7或WxLYvCrM2EmxFTANf8wXmmE7DWjhx5N 24 | 25 | 虽然可以用许多文本格式（例如，十六进制、base64等）表示多散列，但对等ID总是使用base58编码，在编码为字符串时没有多基前缀 26 | 27 | ## 多地址中的Peer ID 28 | 29 | 对等体ID可以作为p2p地址编码到多地址中，并将对等体ID作为参数。 30 | 31 | 如果我的对等ID是QmYyQSo1c1Ym7或WxLYvCrM2EmxFTANf8wXmmE7DWjhx5N，则我的libp2p多地址为 32 | 33 | ```markdown 34 | /p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N 35 | ``` 36 | 37 | 与其他多地址一样，可以将P2P地址封装到另一个多地址中，以组成一个新的多地址。例如，我可以将上面的内容与**传输地址/ip4/198.51.100.0/tcp/4242**结合起来，生成这个非常有用的地址： 38 | 39 | ```markdown 40 | /ip4/198.51.100.0/tcp/4242/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N 41 | ``` 42 | 43 | 这提供了足够的信息，可以通过TCP/IP传输拨打特定的对等方。在拨号过程中，如果遇到了IP地址或端口被其他节点使用的情况，由于Peer ID是由密钥生成的，因此控制该IP地址或端口的节点将无法使用相同的Peer ID，这一点很容易被察觉。因此，通过Peer ID来标识节点，能够帮助我们避免遇到恶意节点的欺诈行为。 44 | 45 | ## Peer Info 46 | 47 | 另一种与对等身份相关的常见libp2p数据结构是PeerInfo结构。 48 | 49 | 对等方信息将对**等方ID与对等方正在侦听的一组多地址**相结合。 50 | 51 | ## Peer store 52 | 53 | ibp2p节点通常会有一个临时存储区来**存储对等密钥、地址和相关元数据**。peer store 的工作原理类似于电话簿或通讯簿；把它想象成一本通用的多地址书，为所有已知的同行维护真实来源。 54 | 55 | 具体而言，Peerstore用于存储以下信息： 56 | 57 | - 节点ID 58 | - 节点地址列表 59 | - 节点公钥等 60 | 61 | Peerstore在P2P网络中扮演着非常重要的角色，因为它允许节点了解其他节点的信息并建立与这些节点的连接。例如，当节点需要与另一个节点进行连接时，它可以在Peerstore中查找该节点的信息，包括其ID和地址等，然后利用这些信息向该节点发起连接请求。 62 | 63 | Peerstore还允许节点根据需要管理其他节点的信息，例如删除过期或不再需要的节点信息，或向Peerstore中添加新的节点信息等。这在处理网络故障和节点失效等情况时非常有用。 64 | 65 | ## Peer Discovery 66 | 67 | 当peer store中没有关于某个节点的信息时，需要使用发现方法来寻找其地址信息。一般情况下，可以通过节点的Peer ID来发现其地址。当一个节点的地址被成功发现并与其建立连接后，其信息（包括Peer ID和地址）将被添加到peer store中，以备后续使用。 68 | 69 | 如果peer store中没有关于某个节点的信息，则需使用发现方法来寻找其地址信息。peer routing guide中提供了有关如何发现未知节点的更多信息。添加新节点信息的过程中，会将该节点的连接地址和节点信息存储在peer store中供其他节点查找和使用。通过这种方式，可以使网络中的节点互相发现和连接，从而增强P2P网络的稳定性和可用性。[广泛的连接协议](https://connectivity.libp2p.io/)。 -------------------------------------------------------------------------------- /Cross_Chain_Technology/跨链方案/跨链桥/multichain.md: -------------------------------------------------------------------------------- 1 | ## 工作原理 2 | 3 | > 分布式密钥算法 4 | 5 | ### 跨链桥 6 | 7 | > 发送资产从A链到B链 8 | 9 | 在资产原始链上，要跨越的资产被发送到一个特殊的SMPC钱包地址并安全地保留在那里，这就是去中心化管理账户。在目标链上，一个智能合约与去中心化管理账户中持有的资产进行1:1的代币交换，并将它们发送到用户的钱包中。反之，当代币被发送到智能合约时，它们将被销毁，然后SMPC节点会将它们释放到原始链上。 10 | 11 | SMPC节点在将一个原始链和一个目标链连接起来时，完全自主地、无需人工干预地执行多个功能： 12 | 13 | - 当创建两个区块链之间的新桥时，SMPC节点会生成一个去中心化管理账户，其地址用于发送资产。这些资产在跨链资产在目标链上创建时被安全保留。这个地址只由SMPC节点控制，而不是由任何人或其他外部所有的地址所控制。 14 | - 同样，在创建两个区块链之间的新桥时，SMPC节点将连接到目标链上的一个新智能合约，用于封装资产。该合约可以由第三方或Multichain团队创建。它用于在目标链上创建新代币，或在将资产赎回到其原始链时销毁它们。该合约可以是AnyswapV5ERC20.sol，也可以是进行了适应性修改以包括项目所需自定义代码的合约，如交易税等。 15 | - MPC节点监视去中心化管理账户。当有新的资产到达时，会触发目标链上的Wrapped Asset智能合约进行代币铸造。 16 | - 如果资产被赎回，MPC节点会触发Wrapped Asset智能合约销毁代币。之后，MPC节点将从去中心化管理账户中释放资产，并将它们发送到原始链上的用户 17 | 18 | ### 跨链路由 19 | 20 | （a）本地资产 21 | 22 | ## 为什么要使用SMPC网络 23 | 24 | 单一签名在跨链资产转移或智能合约互操作时的单点故障问题。如果只使用一个签名来发送资产或与跨链智能合约交互，那么这个签名就是整个操作的单点故障。如果这个签名的私钥管理不当，就可能被攻击者利用，导致资产被盗或智能合约被篡改。多重签名钱包是解决这个问题的一种方式（发送方和服务托管商或者合作伙伴作为多重签名），但是它也存在一些问题：这些多重签名的私钥仍然是外部拥有地址（Externally Owned Addresses）；签名者必须预先定义，这导致这种方案缺乏灵活性；签名地址是公开的，这使得访问权限结构是众所周知的；同时加密以及用于签名的数据可能很大，可能需要多个密钥。 25 | 26 | 解决方案是使用阈值签名方案（TSS），将密钥拆分。从n个可能的签名者中，至少有t个（n/2+1≤t≤n）签名者可以签署交易。至少只有t个串通的玩家才能伪造签名。这具有以下优点： 27 | （a） 它是私有的，所以没有人知道使用了哪些t签名， 28 | （b） 如果有许多可能的签署方，那么可以选择表现良好的签署方， 29 | （c） 它是有效的，因为链上只有一个签名，看起来像一个常规签名。 30 | 31 | TSS全称Threshold Signature Scheme，是一种基于分布式算法的签名方案，可以在多个签名者之间进行安全且高效的签名操作。TSS方案的目的是在多个参与方之间，实现对一个签名中的私钥进行分享，并且只有在设定的门限值以上的参与方共同合作才能恢复出原始的签名，从而实现更安全的数字签名应用。TSS方案通常使用在区块链技术中，特别是在多方进行多签名、跨链交互这些场景中。 32 | 33 | 目前，有一些TSS方案已经呈现出较成熟的实现。例如，dFinity发布的Hige Threshold Scheme方案，以及由公司 Unbound 基于 MPC（multi-party computation）技术实现的TSS方案。此外，还有一些开源的TSS方案，例如CryptoLib4PBC和ToinLeit这两个库都实现了TSS方案，并提供了可直接使用的API接口。而在以太坊智能合约层，已经有一些现成的TSS合约实现库，例如BarnBridge团队开发的Solidity语言合约库bonded curve购买和赎回合约中就大量使用了TSS方案。 34 | 35 | ## 安全模型 36 | 37 | ### 门限分布式签名算法 38 | 39 | SMPC是一种基于安全多方计算的阈值分布签名算法，用于 Multichain 跨链解决方案。该算法能够在独立运行的节点上生成一组私钥，并通过分布式计算生成相应的公钥。与秘密共享等技术相比，该算法不会显示完整的私钥，因此无法访问或显示私钥。此外，在分布式计算期间，每个节点不会彼此传递它们持有的私钥。多方计算确保在分布式计算期间生成的中间结果无法用于推导相应的私钥。 40 | 41 | 将该算法应用于数字资产的跨链连接是一种去中心化的方式，可安全有效地处理数字资产。 42 | 43 | ### SMPC网络 44 | 45 | 它由几个独立运行和维护的节点组成，这些节点在需要初始化生成公钥或执行签名时执行阈值分布签名算法。 46 | 47 | 为实现数字资产的跨链交互，需要将MPC网络作为一个分布式网络，以便在链之间实时处理跨链请求。这反映在触发机制上，即实时检测原始链上的状态，然后将其转换为目标链上的行为。当前的MPC网络是一个分布式系统。每个节点将独立验证原始链的状态，并使用所有节点之间的阈值分布签名算法，以达成对验证结果的共识。 48 | 49 | 基于密码算法的这种方法可以产生强大的共识。它要么产生一致的正确结果，要么没有结果。这确保了Multichain的MPC网络能够准确处理跨链请求。 50 | 51 | 52 | 53 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/密码学中的数学/代数基础/代数_群.md: -------------------------------------------------------------------------------- 1 | # 详解群的定义、性质和分类 2 | 3 | ## 1. 引言 4 | 5 | 群（Group）是代数学中的一种数学结构，被广泛应用于各个数学领域和物理学中。它是数学中最具有抽象性的一个概念之一，概括了数学中许多重要的理论和方法，同时在数值模拟和编程领域中也具有重要的应用。本文将详细介绍群的定义、性质和分类，以帮助读者深入理解这一数学概念。 6 | 7 | ## 2. 群的定义 8 | 9 | 群是一个集合 $G$ 和一个二元运算 $*$ 具有一下4个性质的数学结构： 10 | 11 | 1. 封闭性：对于 $a,b \in G$，$a*b$也在G中； 12 | 2. 结合律：对于 $a,b,c \in G$，$(a*b)*c=a*(b*c)$； 13 | 3. 恒等元：存在一个元素 $e \in G$ 使得 $\forall a \in G$，$a*e=e*a=a$； 14 | 4. 逆元：对于群 $G$ 中的任意元素 $a$，存在一个元素 $a^{-1}$，使得 $a*a^{-1}=a^{-1}*a=e$。 15 | 16 | 凭直觉，这意味着群的任意两个元素都可以通过群运算相互转换，并且第四个性质要求群的每个元素都有一个可逆元素（也就是逆元素），使得对于每个元素 $a$，乘以它的逆元素等于单位元素 $e$。而群运算 $*$ 必须满足封闭性和结合律，这是“运算”属性的基本的需求，另外也必须满足交换律。如果运算 $*$ 满足交换律，则称群为“可交换群”或阿贝尔群。 17 | 18 | ## 3. 群的性质 19 | 20 | ### 3.1 单位元和逆元的唯一性 21 | 22 | 任何群都必须具有唯一的单位元素，用 $e$ 表示。如果一个群有两个不同的单位元素 $e'$ 和 $e''$，那么由于 $e'$ 是群的一个单位元素，所以有 $e' * e'' = e''$；同样， $e''$ 也是一个单位元素，有 $e' * e'' = e'$。这样就得到 $e''=e'$，也就是说，群的单位元素必须惟一。 23 | 24 | 群元素的逆元素也必须惟一。对于同一个群元素 $a$，必须存在唯一的元素 $a^{-1}$，满足 $a * a^{-1} = a^{-1} * a = e$。 25 | 26 | ### 3.2 群的运算具有消去律 27 | 28 | 如果一个群运算 $*$ 具有消去律，即对于群 $G$ 中的任两个元素 $a$ 和 $b$，如果 $a * c = b * c$，那么 $a = b$（其中 $c$ 是 $G$ 的一个任意元素），则称群 $(G, *)$ 具有消去律。一般而言，形如复数的群运算是没有消去律的，但像矩阵这种多维度的群，在有特定的限制条件下是可以具有消去律的。 29 | 30 | ### 3.3 群的幂等性和逆幂等性 31 | 32 | 对于群 $(G, *)$ 中的任何元素 $g$，都有幂等性质：$g * g = g^2$，即群元素自乘的结果仍然是这个群的元素。此外，如果 $a * b = e$，那么 $a$ 和 $b$ 互为逆元素，即 $a=b^{-1}$ 且 $b=a^{-1}$。这种反向操作的性质称为逆幂等性。 33 | 34 | ### 3.4 群的左陪集和右陪集 35 | 36 | 如果 $H$ 是群 $G$ 的一个子集，$a \in G$，则 $aH = \{ah | h \in H\}$ 称为 $H$ 的左陪集，$Ha = \{ha | h \in H\}$称为 $H$ 的右陪集。陪集具有下列性质： 37 | 38 | 1. 两个不同的左陪集是不想交的； 39 | 2. 两个不同的右陪集是不想交的； 40 | 3. 所有左陪集的并构成了 $G$，所有右陪集的并构成了 $G$； 41 | 4. 一个元素 $g$ 在 $H$ 的左陪集中当且仅当 $a_1 * g = a_2$，其中 $a_1$ 属于 $H$。 42 | 43 | ### 3.5 子群的定义 44 | 45 | 设 $(G, *)$ 是群，如果 $H$ 是 $G$ 的非空子集，而且 $H$ 对 $G$ 中定义的群运算 $*$ 封闭，且在 $H$ 中存在单位元素 $e$，那么称 $H$ 是 $G$ 的子群。 46 | 47 | ## 4. 群的分类 48 | 49 | ### 4.1 有限群与无限群 50 | 51 | 群可以分为两类：有限群和无限群。如果群具有有限个元素，则称该群为有限群，否则称该群为无限群。 52 | 53 | ### 4.2 压缩群与离散群 54 | 55 | 压缩群和离散群是几何对象的数学描述。如果一个群具有连续的性质，像实数一样，那么它被称为压缩群。如果一个群是一个离散对象的群，如整数或布尔代数，那么称这个群为离散群。 56 | 57 | ### 4.3 有限生成群 58 | 59 | 有限生成群是指存在有限个元素，使它们的各种组合可以得到群中的所有元素。例如，整数加群就是一个有限生成群。 60 | 61 | ### 4.4 简单群 62 | 63 | 简单群是指任意非平凡子群都与整个群相等的群，即没有非平凡的正规子群。可以证明一个群是有限简单群当且仅当它不能表示成其他有限简单群的直积。 64 | 65 | ### 4.5 循环群 66 | 67 | 循环群是由一个元素通过重复作用群运算所生成的群，其中这个元素称为生成元。例如，模 $n$ 的整数环中的循环群 $C_n$，就是由一个元素 $a$ 作用群运算 $+$ 所生成的群，满足 $a, a + a, a + a + a, \ldots, a + (n-1)a$ 是整数环的完整集合。 68 | 69 | -------------------------------------------------------------------------------- /Public_Chain_Development/Consensus_Mechanisms/死磕共识算法_POS算法-2.md: -------------------------------------------------------------------------------- 1 | > 死磕共识算法|POS算法 2 | > 3 | > 配合以下代码进行阅读：https://github.com/blockchainGuide/ 4 | > 5 | > 写文不易，给个小关注，有什么问题可以指出，便于大家交流学习。 6 | 7 | ![u=2232051863,378698187&fm=26&gp=0](https://tva1.sinaimg.cn/large/008eGmZEgy1gn96oqcxsyj30dw08pjs7.jpg) 8 | 9 | 10 | 11 | # 为什么会出现PoS? 12 | 13 | ​ 在比特币系统中采用了`PoW`(工作量证明）算法,`PoW`其实就是由所有的节点相互竞争，提交一个难于计算但是容易验证的计算结果，任何节点都可以验证这个这个结果的正确性，验证通过即算这个节点完成了大量的计算工作。 14 | 15 | ​ 然而`PoW`机制存在明显的弊端。 一是算力不公平，矿场的竞争力比单个节点大，还有就是随着硬件的发展，特别是量子计算机的出现，可能几秒就破解了`Hash`。 二是`PoW`算法太浪费了，比特币网络每秒可完成数百万亿次`SHA256`计算， 但这些计算除了使恶意攻击者不能轻易地伪装成几百万个节点和打垮比特币网络，并没有更多实际或科学价值。 16 | 17 | ​ 鉴于以上问题，POS`股权证明`诞生了。 18 | 19 | # PoS股权证明 20 | 21 | ​ 权益证明（ Proof of Stake，PoS） ，最早在 2013 年被提出，最早在 `Peercoin` 系统中被实现，类似现实生活中的股东机制，拥有股份越多的人越容易获取记账权（ 同时越倾向于维护网络的正常工作） 。 22 | 23 | ​ 典型的过程是通过保证金（ **代币、资产、名声等具备价值属性的物品**） 来对赌一个合法的块成为新的区块，收益为抵押资本的利息和交易服务费。提供证明的保证金（ 例如通过转账货币记录） 越多，则获得记账权的概率就越大。合法记账者可以获得收益。 24 | 25 | ​ 恶意参与者将存在**保证金**被罚没的风险，即损失经济利益。一般的，对于 PoS 来说，需要掌握超过全网 **1/3** 的资源，才有可能左右最终的结果。这个也很容易理解，三个人投票，前两人分别支持一方，这时候，第三方的投票将决定最终结果。 26 | 27 | ​ 在股权证明模式下， 有一个名词叫**币龄**， 每个币每天产生1币龄， 例如，你持有 100 个币， 总共持有了 30 天， 那么， 此时你的币龄就为 3000， 这个时候， 如果你发现了一个`PoS`区块， 你的币龄就会被清空为 0。 你每被清空 365币龄， 你将会从区块中获得0.05个币的利息（ 可以理解为年利率5%） ， 那么在这个案例中， 利息`=3000×5%/365=0.41`个币。 28 | 29 | ​ 以现有的比特币运行发展情况来看， 比特币每年的挖矿产量都在不断减半， 我们可以预计， 随着比特币产量的不断降低， 矿工人数也会越来越少， 这样就会**导致整个比特币网络的稳定性出现问题**。 PoS的解决方案是鼓励大家都去打开钱包客户端程序， 因为只有这样才可以发现PoS区块， 才会获得利息， 这也增加了网络的健壮性。还有当矿工数量变少的时候，比特币被51%算力攻击就越容易。 30 | 31 | # PoS 的优缺点 32 | 33 | ## 优点 34 | 35 | 1. 省资源：不需要挖矿，不需要大量耗费电力和能源。 36 | 2. 更加去中心化：相对于比特币等PoW类型的加密货币，更加去中心化，相比PoW算法的51%算力攻击，PoS需要购买51%的货币，成本更高，没有攻击意义。 37 | 3. 避免通货膨胀：PoS机制的加密货币按一定的年利率新增货币，可以有效避免紧缩出现，保持基本稳定。 38 | 39 | ## 缺点 40 | 41 | 1. POS会面临发币的问题，起初只有创世块上有币，意味着只有这个节点可以挖矿，所以让币分散出去才能让网络壮大，所以早期采取的是POW+POS，即第一阶段POW挖矿，第二阶段POS挖矿，后来ERC20合约代币出现后，可以只存在POS的挖矿形式。 42 | 2. 开发者作恶：纯`PoS`机制的加密货币，只能通过`IPO`的方式发行，这就导致“少数人”（通常是开发者）获得大量成本极低的加密货币，很有可能造成大面积的抛售。 43 | 3. 币龄其实就是时间，一旦挖矿者囤积一定的币，很久很久之后发起攻击，这样将很容易拿到记账权。 44 | 4. 矿工可以囤积代币从而导致货币流通困难。 45 | 5. POS面临的最严重的一个问题就是无成本利益问题，在PoS系统中做任何事几乎没有成本，比如在PoS系统上挖矿几乎没有成本，这也就意味着分叉非常方便。 46 | 47 | # 参考 48 | 49 | > https://github.com/blockchainGuide 50 | > 51 | > https://eth.wiki/en/concepts/casper-proof-of-stake-compendium 52 | > 53 | > https://eth.wiki/en/concepts/casper-proof-of-stake-compendium 54 | > 55 | > https://eth.wiki/en/concepts/proof-of-stake-faqs 56 | > 57 | > https://www.cnblogs.com/sueyyyy/articles/9726812.html -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/ton/ton开发/NFT.md: -------------------------------------------------------------------------------- 1 | ## Ton类型 2 | 3 | - 艺术品 4 | - 收藏品 5 | - 会员资格 6 | - https://ton.diamonds/collection/the-gateway/yyx-ticket-19 7 | - TON DNS域名 8 | - https://ton.diamonds/zh/collection/ton-dns-domains?tab=items 9 | - telegram username 10 | - https://getgems.io/collection/EQCA14o1-VWhS2efqoh_9M1b_A9DtKTuoqfmkn83AbJzwnPi 11 | - 匿名号码 12 | - 可创建于sim卡无关的telegram账号 13 | - 代金券 14 | - no tcoin玩法 ： https://getgems.io/collection/EQDmkj65Ab_m0aZaW8IpKw4kYqIgITw_HRstYEkVQ6NIYCyW 15 | - 可转成真实代币 16 | 17 | 18 | 19 | https://fragment.com/about 20 | 21 | https://getgems.io/ 22 | 23 | https://ton.diamonds/ 24 | 25 | https://beta.disintar.io/collection/UQAv9X13hopdcDCO3azadyHy3mqIjzPgr0_fdrUdXjtpZmdK 26 | 27 | ## 基本实现 28 | 29 | 你要创建新的NFT项目，向集合合约发送消息，他就会根据你提供的数据创建一个NFT合约 30 | 31 | 32 | 33 | ## TON NFT 标准 34 | 35 | - 每个NFT 物品和NFT 集合都是单独的智能合约,你发布了包含10000个项目的集合，则会部署100001个合约 36 | 37 | 38 | 39 | ## NFT元数据 40 | 41 | 每个NFT物品和NFT集合本身都有自己的元数据，元数据可以是链下（链接）或者链上（存储于智能合约中） 42 | 43 | NFT物品元数据： 44 | 45 | ```json 46 | { 47 | "name": "TON Smart Challenge #2 Winners Trophy", 48 | "description": "TON Smart Challenge #2 Winners Trophy 1 place out of 181", 49 | "image": "https://ton.org/_next/static/media/duck.d936efd9.png", 50 | "content_url": "https://ton.org/_next/static/media/dimond_1_VP9.29bcaf8e.webm", 51 | "attributes": [] 52 | } 53 | ``` 54 | 55 | NFT集合元数据： 56 | 57 | ```json 58 | { 59 | "image": "https://ton.org/_next/static/media/smart-challenge1.7210ca54.png", 60 | "name": "TON Smart Challenge #2", 61 | "description": "TON Smart Challenge #2 Winners Trophy", 62 | "social_links": [] 63 | } 64 | ``` 65 | 66 | 67 | 68 | ## 缺点 69 | 70 | > 无法理解 71 | 72 | 由于 TON 是异步区块链，因此无法获取链上 NFT 的当前所有者。当包含有关 NFT 所有者的信息的消息被传递时，此信息可能会变得无关紧要，因此我们无法保证当前所有者没有发生变化。 73 | 74 | 75 | 76 | ## 为什么他不是tokenId->owner_address 的单一合约 77 | 78 | - 基于异步，他无法知道谁的消息会先到达，在复杂的交互链上（比如钱包到NFT合约再到拍卖合约），运行时无法确认字典大小（存储消耗gas）， 即无法预测消耗的gas,那么久可能出现前面的几步操作成功，到了拍卖失败了。 而如果是采用单个合约的话，合约的状态是不会随着执行改变的 79 | - 无法扩展，TON在负载下会分为分片链，如果交易都是引用同一个合约，大大限制处理速度。 TON提供了分片智能合约，未实施 80 | 81 | 82 | 83 | ## 不存在approve 84 | 85 | 在同步区块链上，比如以太坊，智能合约可以一次性检查代币的所有权、批准和转账权限，确保所有条件都满足后才执行转账操作。然而，在TON这样的异步区块链上，由于消息处理的不确定性，这种方法不再适用。在TON上，为了确保操作的正确性，需要发送多条消息来执行相同的操作，并在每条消息的响应中检查是否出现错误，如果出现错误，则需要执行回滚操作。 86 | 87 | 这种方法不仅复杂，而且效率低下，因为它增加了网络交互的次数和潜在的错误处理成本。 88 | 89 | 90 | 91 | ## 存在的问题 92 | 93 | - 还没有标准方法来安全转移， 合约执行失败，会恢复所有权的转移 94 | 95 | 96 | 97 | -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕libp2p之流复用.md: -------------------------------------------------------------------------------- 1 | # 流复用 2 | 3 | libp2p是基于流抽象构建的，并使用**双向消息流**在节点之间发送数据。然而，仅依赖两个节点之间的单个消息流可能会导致可扩展性问题和瓶颈。每个连接的两端的节点可能会运行多个应用程序，通过流发送和等待数据。单个流会阻塞彼此间的应用程序，因为一个应用程序需要等待另一个应用程序完成利用流后才能发送和接收自己的消息。 4 | 5 | 为解决这个问题，libp2p允许应用程序使用流多路复用。**多路复用允许在单个连接中创建多个“虚拟”连接**。这使节点可以通过单独的虚拟连接发送多个流的消息，提供可扩展的解决方案，消除单个流创建的瓶颈。**两个libp2p节点可以有一个TCP连接，并使用不同的端口号来区分流**。然后像IPFS使用的Kademlia或GossipSub这样的不同应用程序/进程会获得自己的数据流，使传输更有效。流多路复用使得运行在libp2p之上的应用程序或协议认为它们是运行在该连接之上的唯一实例。另一个例子是HTTP/2将流引入了HTTP中，允许在同一个连接上并行执行多个HTTP请求。 6 | 7 | 综上所述，流复用可以被用于在libp2p之上的应用程序之间共享单个连接，提供更有效的解决方案，特别是在建立连接开销很大时，例如需要进行NAT打洞时。通过仅建立一次连接并通过同一连接运行多个流，libp2p可以减少与频繁建立连接相关的资源开销和延迟惩罚。 8 | 9 | ## libp2p中的流复用器 10 | 11 | 流连接多路复用器是libp2p栈的关键组件，为节点提供可插拔的多路复用功能。libp2p主机可以**同时支持多个多路复用器**，并且节点之间在初始连接握手期间协商多路复用器的选择。此协商协议允许libp2p在未来采用新的多路复用器并保持向后兼容性与现有多路复用器。 12 | 13 | 💡 14 | 对于构建libp2p应用程序的开发人员，与流连接多路复用器的交互通常仅限于初始配置阶段。libp2p栈自动处理多路复用器的协商和设置，确保所有连接都是流多路复用的，并允许在单个连接上无缝传输多个流的数据。 15 | 16 | 当前，libp2p支持两个流连接多路复用器，即mplex和yamux。然而，libp2p栈中可用的许多传输协议都具有本地流连接，例如QUIC，WebTransport和WebRTC，在这些情况下，libp2p不需要执行流多路复用，因为协议已经提供了它。 17 | 18 | # Switch 19 | 20 | libp2p通过名为交换机（或“swarm”（根据实现不同））的组件**维护关于已知节点和现有连接的一些状态**。 该交换机提供了一种拨号和监听接口，用于抽象给定连接所使用的流多路复用器的详细信息。 21 | 22 | 在配置libp2p时，应用程序启用流多路复用模块，当拨号节点并监听连接时，交换机将使用这些模块。如果远程节点支持任何相同的流多路复用器实现，则在建立连接时交换机将选择并使用它。如果您拨打交换机已经存在的一个已经打开的连接的节点，新的数据流将自动启用现有连接进行多路复用。 23 | 24 | 在连接建立过程的早期阶段，就会协商选用哪种流多路复用器。节点使用协议协商来协商共同支持的多路复用器，该多路复用器将“原始”传输连接升级为能够打开新流的复用连接。 25 | 26 | # mplex 27 | 28 | mplex是libp2p早期设计的一个简单的流连接多路复用器。它是一个简单的协议，不提供其他流连接多路复用器提供的许多功能。值得注意的是，**mplex不提供流量控制，这是现在被认为是流连接多路复用器的关键功能之一**。 29 | 30 | mplex在两个对等方之间的可靠、有序的通道上运行，例如TCP连接。对等方可以打开、写入、关闭和重置一个流。mplex使用像yamux一样的基于消息的编帧层，使其能够复用不同的数据流，包括面向流的数据和其他类型的消息。 31 | 32 | 缺点： 33 | mplex没有任何流量控制。 34 | 35 | Backpressure是一种机制，用于防止一个节点压垮耗时的数据的接收端。 36 | 37 | mplex也不限制节点可以打开的数据流的数量。 38 | 39 | 在libp2p中应该使用Yamux而不是mplex。因为Yamux本身支持流量控制，所以更适用于需要传输大量数据的应用程序。 40 | 41 | 直到最近，mplex仍然受到支持的原因是与没有yamux支持的js-libp2p兼容。现在js-libp2p已经具备了yamux支持，所以仅应使用mplex来提供向遗留节点提供向后兼容性。 42 | 43 | # Yamux 44 | 45 | Yamux（又一个多路复用器）是libp2p中使用的强大的流连接多路复用器。它最初由Hashicorp为Go开发，现在在Rust、JavaScript和其他语言中实现。 它在**单个TCP连接上允许多个并行数据流**。它的设计灵感来自SPDY（后来成为HTTP / 2的基础），但它与它不兼容。 46 | 47 | Yamux的关键特性之一是其支持通过**背压进行流量控制**。该机制用于在数据发送方和接收方之间协调数据传输速度的方法。当数据发送方发送数据的速度超过接收方处理数据的速度时，就会发生背压。接收者可以发送一个信号给发送方，表示它无法快速处理所有数据，并请求发送方减慢数据的发送速度。这种机制可以防止接收器被淹没并导致数据丢失，同时可以尽可能地提高数据吞吐量。这种机制在许多网络应用程序的设计中是至关重要的，因为它有助于保持网络流畅并防止资源浪费 48 | 49 | **在libp2p中应该使用Yamux而不是mplex，因为mplex不提供在流程级别上应用背压的机制。** -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/zkroullup/zkbnb.md: -------------------------------------------------------------------------------- 1 | ![image-20221118125400482](/Users/carver/Library/Application Support/typora-user-images/image-20221118125400482.png) 2 | 3 | 用户需要在bsc上的ERC20代币绑定到zkbnb 上，无法将代币在上面流通 4 | 5 | 支持用户在Layer1和Layer2之间进行NFT和FT的传输 6 | 7 | 用户将代币存储在BSC上的rollup合约上进入到ZKroullup,ZkBNB监视器将跟踪存款并将其作为第二层交易提交，一旦提交人验证了交易，用户就可以在其账户上获得资金，他们可以通过将交易发送给提交人进行处理来开始交易。 8 | 9 | 用户可以通过向网络发送签名的交易来将任何数量的资金转移到ZKBNB上的任何帐户。 10 | 11 | 用户启动提款交易，资金将在 ZkBNB 上烧毁。一旦对下一批中的事务进行了rolliup，相关数量的token将从rollup contract解锁到目标帐户。 12 | 13 | 14 | 15 | 所有的买入/卖出报价、NFT/Collection的元数据、媒体资源、账户配置文件都存储在NFT市场的后端，只有竞争的Hash、所有权、creatorTreasuryRate和其他字段记录在ZkBNB上。为了鼓励价格发现，**任何人都可以在市场上购买/出售报价，而无需支付任何费用**，因为报价缓存在后端，而不是发送到ZkBNB。一旦报价匹配，由买入和卖出报价组成的AtomicMatch交易将发送给ZkBNB，以实现交易。用户还可以通过发送取消报价事务以禁用后端缓存的报价来手动取消报价 16 | 17 | 18 | 19 | ZkBNB 上的每个帐户都有其简称，用户可以使用它来存储资金并接收任何加密货币、令牌或 NFT。 20 | 21 | ZkBNB本机支持ECDSA签名并遵循EIP712签名结构，这意味着大多数以太坊钱包可以无缝支持ZkBNB。BSC用户没有额外的努力来利用ZkBNB。 22 | 23 | 24 | 25 | 与大多数将状态树放入内存的汇总解决方案不同，BAS-SMT 是一种用于持久数据的版本化、快照表(不可变)稀疏树。BAS-SMT 是 ZkBNB 大规模应用的关键因素https://github.com/bnb-chain/zkbnb-smt/ 26 | 27 | 28 | 29 | ZkBNB Crypto是描述证明电路的库。一旦ZK汇总节点有了足够的事务，它就将它们聚合成一批，并为证明电路编译输入，以编译成一个简洁的ZK证明 https://github.com/bnb-chain/zkbnb-crypto 30 | 31 | 32 | 33 | ## ZKbnb contract 34 | 35 | 这是layer 2的入口和出口。 36 | 37 | zkBNB合约提供以下特性： 38 | 39 | L1安全：ZkBNBVerifier 协议可以验证 **Layer2**生成的 SNARK 证明(简洁的非交互式知识论证) ，从而证明汇总块中每个事务的有效性。所以 ZkBNB 和 BSC 共享同样的安全系统。由于 zkSNARK 的证明，安全性是由密码学保证的。用户不必信任任何第三方，也不必为了防止欺诈而不断监视 Rollup 块。 40 | 41 | L1到L2沟通：ZkBNB合同公开了几个支持BNB的接口，在BSC或ZkBNA上创建的BEP20/BEP721可以自由地流向ZkBNC。 42 | 43 | L2到L1的沟通：每个rollup L2块包括一批需要由 L1 合约处理的 L2操作 44 | 45 | BSC上的完全退出：如果用户认为自己的交易受到ZkBNB的审查，可以通过L1智能合约请求提取资金 46 | 47 | 验证器将块从L2提交到L1，这些块将存储在L1上，以供以后验证。提交一个块包括以下步骤： 48 | 49 | - 必须是治理合约中的validator(怎么成为validator 50 | - 上一个块必须是存储在合约中的最新快 51 | - commitOneBlock 52 | - 校验number和timestamp 53 | - 检查链上操作 54 | - 交易类型RegisterZNS CreatePair UpdatePairRate Deposit DepositNft Withdraw WithdrawNft FullExit FullExitNft 55 | - 这些交易类型是定义在layer 2上的 56 | - 注册ZNS名称 57 | - 为 L2上的token swap创建token Pair 58 | - 令牌对的更新费率 59 | - 将代币从L1存入L2 60 | - 将NFT从L1存放到L2 61 | - 从 L2提取令牌到 L1，向 L2发送请求 62 | - 将 NFT 从 L2撤回到 L1，向 L2发送请求 63 | - 从L2向L1请求退出令牌，向L1发送请求 64 | - 请求从L2到L1退出NFT，向L1发送请求 65 | - 最终生成一个可执行的操作hash 和处理的优先级操作 66 | - 为验证证明创建区块承诺（只跟前一个区块和新区块有关，需要上个区块的state root ） 67 | - 最后返回这些验证信息（需要详细列出这些信息） 68 | 69 | CommitBlock包含块信息、事务数据和事务执行后的状态根。块信息包含时间戳、blockNumber和blockSize。二级事务打包在CommitBlockInfo.publicData中 70 | -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕libp2p之协议.md: -------------------------------------------------------------------------------- 1 | # libp2p协议 2 | 3 | ## 协议ID 4 | 5 | ibp2p协议具有唯一的字符串标识符，这些标识符在首次打开连接时用于协议协商过程 6 | 7 | > /my-app/amazing-protocol/1.0.1 8 | 9 | 如果有重大更改，会产生新的版本号。 10 | 11 | ## 处理函数 12 | 13 | 当传入流被标记为注册的协议 ID 时，将调用对应的处理函数。 14 | 15 | ## 二进制流 16 | 17 | libp2p 协议传输的“介质”是具有以下属性的双向二进制流： 18 | 19 | - 每一方都可以**随时从流中读取和写入** 20 | - 数据的**读取顺序与写入顺序相同** 21 | - 可以是“半封闭”，即写封闭读开，或者读封闭写写 22 | 23 | libp2p 还将确保流的[安全](https://docs.libp2p.io/concepts/secure-comms/)和高效 [多路复用](https://docs.libp2p.io/concepts/stream-multiplexing/)。这对协议处理程序是透明的，协议处理程序通过流读取和写入未加密的二进制数据。 24 | 25 | 二进制数据的格式以及何时以及由谁发送什么的机制都由协议决定。 26 | 27 | ## 协议协商 28 | 29 | 当 dial out 以启动新的流时，libp2p将发送您想要使用的协议的协议id。另一端的监听peer将根据注册的协议处理程序检查传入的协议id。 30 | 31 | 如果不支持请求的协议，它将结束流，并且拨号peer可以使用不同的协议重试，或者可能使用最初请求的协议的回退版本。 32 | 33 | 如果支持该协议，则侦听对等方将回显协议id，作为将来通过流发送的数据将使用商定的协议语义的信号。 34 | 35 | 这种就给定流或连接使用什么协议达成一致的过程称为协议协商。 36 | 37 | ## 协议匹配 38 | 39 | - 通过协议ID匹配 40 | - 协议ID没有确切的匹配，模糊匹配 41 | 42 | ## dial 特定协议 43 | 44 | 当拨号给远程Peer以打开新流时，发起对等端会发送他们想要使用的协议id。远程对等方将使用上述匹配逻辑来接受或拒绝该协议。如果协议被拒绝，拨号对等方可以重试。 45 | 46 | 拨号时，您可以选择提供一个**协议id列表**，而不是单个id。当您提供多个协议id时，将依次尝试每个协议id，如果远程对等方至少支持其中一个协议，则将使用第一个成功匹配。拨号端可以回退到和远程端匹配的版本。 47 | 48 | ## 核心libp2p协议 49 | 50 | ### 常见模式 51 | 52 | 下面描述的协议都使用协议缓冲区（又名protobuf）来定义消息模式。 53 | 54 | 消息是使用一个非常简单的约定通过有线进行交换的，该约定在二进制消息payload前面加一个整数，该整数表示**有效载荷的长度**（以字节为单位）。长度被编码为protobuf-variant（可变长度整数）。 55 | 56 | ### ping 57 | 58 | > /ipfs/ping/1.0.0 59 | 60 | ping协议是一种简单的活跃度检查，对等方可以使用它来快速查看另一个对等方是否在线。 61 | 62 | 在初始协议协商之后，拨号对等方发送**32字节的随机二进制数据**。监听对等端回显数据，拨号对等端将验证响应并测量请求和响应之间的延迟。 63 | 64 | ### identify 65 | 66 | > /ipfs/id/1.0.0 67 | 68 | 识别协议允许对等方交换关于彼此的信息，尤其是它们的公钥和已知网络地址。 69 | 70 | 基本识别协议通过使用上表中所示的识别协议id建立到对等端的新流来工作。 71 | 72 | 当远程对等端打开新的流时，他们将填写一条Identify protobuf消息，其中包含关于他们自己的信息，例如他们的公钥，该公钥用于派生他们的对等端ID。 73 | 74 | 重要的是，Identify消息包括一个observedAddr字段，该字段包含对等方观察到请求的多地址。这有助于对等方确定其NAT状态，因为它允许他们查看其他对等方观察的公共地址，并将其与自己的网络视图进行比较。 75 | 76 | 在P2P网络中，对等方可能被部署在不同的网络中，包括NAT（网络地址转换）网络。NAT网络中的设备无法直接访问来自外部网络的数据包，因为它们被阻止或者重定向到本地网络。为了克服这种情况，对等方需要在网络上建立一个多地址视图，以便其他对等方了解它们的公共地址。观察到请求的多地址可以让对等方更好地理解自己的网络情况，并比较其视图与其他对等方观察到的公共地址之间的差异。这有助于对等方更好地了解其NAT状态，并更好地管理其网络资源 77 | 78 | ### identify/push 79 | 80 | 与identify略有不同，identify/push 协议发送相同的identify消息，但它是主动发送的，而不是响应请求。 81 | 82 | 如果对等端开始监听新地址，建立新的中继电路，或者使用标准identify协议从其他对等端获悉其公共地址，这是有用的。在创建或获悉新地址后，对等方可以将新地址推送给其当前知道的所有对等方。这样可以使每个人的路由表保持最新，并使其他对等方更有可能发现新地址 83 | 84 | ## Circuit Relay 85 | 86 | > /libp2p/circuit/relay/0.1.0 87 | 88 | libp2p提供了一种协议，用于在两个对等体无法直接连接时通过中继对等体隧道传输流量。 89 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/基础/完全同态加密.md: -------------------------------------------------------------------------------- 1 | # 完全同态加密 2 | 3 | 完全同态加密（Fully Homomorphic Encryption，FHE）是一种允许对密文数据进行计算并获得加密结果的密码学技术。换句话说，**使用完全同态加密技术，你可以在不解密数据的情况下对其进行计算，并得到一个加密的结果。当需要查看计算结果时，再使用密钥解密**。这种加密技术在数据隐私和云计算安全等领域具有重要的应用价值。 4 | 5 | ## 完全同态加密的定义和性质 6 | 7 | 一个加密方案被称为完全同态加密，如果它满足以下性质： 8 | 9 | 1. **同态性**：在加密数据上进行的计算与在明文数据上进行的计算具有相同的效果。例如，对于任意两个密文c1和c2，以及对应的明文m1和m2，存在一个操作⊕，使得**c1⊕c2等于Encrypt(m1+m2)**。 10 | 2. **完全性**：加密方案支持任意计算功能。这意味着，通过适当的加密操作，可以在密文上实现任意复杂的计算，而无需先解密数据。 11 | 3. **安全性**：完全同态加密方案应提供足够的安全性，以防止未经授权的解密。通常，安全性由计算困难问题（如大数分解问题或离散对数问题）保证。 12 | 13 | ## 完全同态加密的发展 14 | 15 | 完全同态加密的概念最早由Rivest等人在1978年提出。然而，长时间以来，完全同态加密一直被认为是密码学中的一个未解之谜。直到2009年，Craig Gentry首次提出了一个基于理想格的完全同态加密方案，实现了对密文数据的任意计算。自那时起，完全同态加密的研究取得了许多重要进展。 16 | 17 | 以下是一些著名的完全同态加密方案： 18 | 19 | - **Gentry的加密方案**：Gentry的方案是基于理想格和学习有错误（Learning With Errors，LWE）问题的。该方案引入了“自举”（bootstrapping）技术，使得计算可以在密文上无限次进行。 20 | - **BGV方案**：Brakerski、Gentry和Vaikuntanathan于2011年提出了一种改进的完全同态加密方案，简称为BGV方案。该方案使用环学习有错误（Ring-LWE）问题，相比Gentry的方案具有更高的效率。 21 | - **FV方案**：Fan和Vercauteren于2012年提出了一种进一步优化的完全同态加密方案，称为FV方案。FV方案在BGV方案的基础上进行了改进，实现了更高的性能和简化的密钥管理。FV方案在实际应用中得到了广泛关注，成为当前最流行的完全同态加密方案之一。 22 | - **TFHE方案**：TFHE（Tormentedly Fast Homomorphic Encryption）方案由Chillotti等人于2016年提出。该方案基于环学习有错误问题和快速傅里叶变换（FFT），实现了对比FV方案更高的计算速度。TFHE方案在某些场景下可以提供非常高的效率，使得完全同态加密在实际应用中变得更为可行。 23 | 24 | ## Gentry方案 25 | 26 | ## Gentry的加密方案 27 | 28 | Gentry的加密方案是第一个实现完全同态加密的密码学方案。该方案基于理想格（ideal lattice）和学习有错误（Learning with Errors，LWE）问题。以下是Gentry方案的主要组成部分： 29 | 30 | 1. **密钥生成**：首先，通过一个特殊的构造过程生成一个理想格。理想格是一种特殊的点阵，它具有数学上的良好性质。然后，从理想格中选择一个“短”向量作为私钥，将整个理想格作为公钥。 31 | 2. **加密**：为了加密一个明文m，需要将m嵌入到理想格的一个点上。具体来说，先在理想格中选择一个随机点，然后将明文m加到这个点上。最后，添加一个小的噪声（即错误），得到密文。 32 | 3. **解密**：解密过程是通过利用私钥（即短向量）将噪声从密文中去除，然后从理想格的点还原出明文m。由于短向量的特殊性质，这个过程可以有效地完成。 33 | 4. **同态操作**：在Gentry的方案中，可以直接对密文进行加法和乘法操作。这意味着我们可以在密文上实现任意多项式函数计算。然而，随着计算的进行，密文中的噪声会逐渐增加，导致解密失败。 34 | 5. **自举**：为了解决噪声累积的问题，Gentry引入了一种称为“自举”的技术。自举实际上是一种递归过程，它将加密方案作为一个函数，对自己的密文进行计算。通过自举操作，可以在保持计算正确性的同时减小密文中的噪声。这使得在密文上可以进行无限次计算，从而实现了完全同态加密。 35 | 36 | 需要注意的是，Gentry的加密方案涉及到许多复杂的数学概念，例如理想格、LWE问题、噪声控制等。在实际应用中，Gentry的方案存在一定的效率问题。 37 | 38 | ## 完全同态加密的应用场景 39 | 40 | 由于完全同态加密允许在密文上进行计算，它在保护数据隐私和云计算安全等方面具有巨大潜力。以下是一些潜在的应用场景： 41 | 42 | 1. **安全的云计算**：在云计算中，用户可以将加密的数据上传到云服务器，然后请求云服务器对加密数据进行计算。由于数据始终保持加密状态，云服务提供商无法访问用户的敏感信息。这为数据隐私提供了强大的保障。 43 | 2. **隐私保护的数据挖掘**：在数据挖掘中，通常需要处理大量敏感数据。通过使用完全同态加密技术，可以在加密数据上进行数据挖掘，避免泄露用户隐私。 44 | 3. **安全的多方计算**：在多方计算场景中，各方需要共同计算一个函数，但又不希望泄露自己的输入数据。完全同态加密可以在不泄露各方输入的情况下，实现多方安全计算。 45 | 46 | 虽然完全同态加密技术具有诸多潜在的应用场景，但目前其计算效率和实用性仍然有待提高。随着密码学和计算机科学的发展，我们可以期待完全同态加密技术在未来得到更广泛的应用。 -------------------------------------------------------------------------------- /DApp_Development/合约基础/solidity_delegatecall.md: -------------------------------------------------------------------------------- 1 | ## Solidity 中的 Delegatecall 2 | 3 | 在 Solidity 中，`delegatecall` 是一种让一个合约调用另一个合约，并使用调用者的存储空间来存储结果的机制。这种调用是低级别的，因为它不仅仅调用另一个合约的函数，还可以在调用者合约的上下文中执行。使用 `delegatecall` 可以实现一些比较高级的合约操作，例如合约升级或安全库的使用。 4 | 5 | ## 语法 6 | `delegatecall` 的语法如下： 7 | ``` 8 | (bool success, bytes memory returnData) = address.delegatecall(functionSignature); 9 | ``` 10 | 其中： 11 | 12 | - `bool success`：标志函数调用是否成功。 13 | - `bytes memory returnData`：包含函数调用结果的字节数组（返回值）。 14 | - `address`：要调用的合约地址。 15 | - `functionSignature`：要调用的目标合约中的函数签名和参数。 16 | 17 | `delegatecall` 函数的返回值包含两个部分：`bool success` 和 `bytes memory returnData`。如果函数调用成功，则 `success` 为 `true`，否则为 `false`。`returnData` 包含函数调用的返回值或错误信息。需要注意的是，由于 Solidity 不支持重载函数，因此 `functionSignature` 必须是被调用函数的确切名称和参数，而不能是同名函数的不同版本。 18 | 19 | ## 应用场景 20 | 21 | 以下是使用 `delegatecall` 的一些常见应用场景： 22 | 23 | ### 1. 安全库 24 | 使用 `delegatecall` 可以实现一种安全库机制，其中合约代码分开分成两部分：一个存储状态和变量的主体合约和一个包含可重用代码片段的合约库。合约主体合约可以使用 `delegatecall` 调用合约库，以便保存并使用库中的状态和逻辑。通过这种方式，合约库可以成为可视为标准软件库的任何安全代码。 25 | 26 | ### 2. 合约升级 27 | 使用 `delegatecall` 机制，可以在不影响存储的情况下更新合约代码。在这种情况下，更新代码的合约将被部署到新的合约地址上，但是它将与旧的合约共享相同的存储空间。这样，新的合约可以使用 `delegatecall` 函数调用旧的合约，获取先前存储的状态，并在新合约中运行更新的逻辑。此举可以节省大量的数据迁移和存储操作。 28 | 29 | ### 3. 协议间调用 30 | 为了让不同的协议之间进行交互，可以使用 `delegatecall` 来调用其他协议包含的合约函数。这可以避免在协议之间传递大量的数据和状态，提高协议之间的互操作性和可扩展性。 31 | 32 | ## 举例 33 | 34 | 以下是一个示例，该示例展示了如何使用 `delegatecall` 调用目标合约： 35 | 36 | ``` 37 | pragma solidity ^0.8.0; 38 | 39 | contract Target { 40 | function getName() public pure returns (string memory) { 41 | return "Target Contract"; 42 | } 43 | } 44 | 45 | contract Caller { 46 | function callGetName(address _target) public returns (string memory) { 47 | (bool success, bytes memory returnData) = _target.delegatecall( 48 | abi.encodeWithSignature("getName()") // 调用目标合约的 getName 函数 49 | ); 50 | require(success, "Delegatecall to target contract failed"); 51 | return abi.decode(returnData, (string)); // 解码返回的字节数组 52 | } 53 | } 54 | 55 | ``` 56 | 57 | ## 注意点和安全性 58 | 59 | 在使用 `delegatecall` 时，存在以下注意点和安全性问题： 60 | 61 | 1. 数据格式和存储不一致。由于 `delegatecall` 可以共享存储，因此合约在更新时需要特别注意确保数据格式和状态保持一致，否则可能会导致合约失败或安全漏洞。 62 | 63 | 2. 冲突名称。由于 `delegatecall` 不会更改调用者合约的 `msg.sender` 值，因此在两个合约具有相同函数名的情况下可能会发生冲突。为了解决这个问题，可以在函数签名中添加一个前缀来确保它们唯一。 64 | 65 | 3. 披露信息。由于 `delegatecall` 可能会导致信息泄露，因此需要小心使用，并使用加密和匿名方式保护敏感信息。 66 | 67 | 4. 通过测试和审计验证代码。在使用 `delegatecall` 之前，需要完成全面的测试和审计，以确保代码和逻辑正确并完全安全。 68 | 69 | 总之，`delegatecall` 是 Solidity 中非常有用的低级函数之一，并在智能合约的开发过程中被广泛使用。但是，在使用之前需要仔细考虑一些问题，并遵循最佳实践，以确保程序的安全和有效性。 -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/op-存款备份.md: -------------------------------------------------------------------------------- 1 | ```solidi 2 | function _isOptimismMintableERC20(address _token) internal view returns (bool) { 3 | return 4 | ERC165Checker.supportsInterface(_token, type(ILegacyMintableERC20).interfaceId) || 5 | ERC165Checker.supportsInterface(_token, type(IOptimismMintableERC20).interfaceId); 6 | } 7 | 这个判断是不是op可以mint的ERC20 8 | 9 | 10 | ``` 11 | 12 | 当用户通过optimal 合约发出质押交易事件（TransactionDeposited），接下来会由OP RollUp client 来处理 13 | 14 | ```GO 15 | // UserDeposits transforms the L2 block-height and L1 receipts into the transaction inputs for a full L2 block 16 | func UserDeposits(receipts []*types.Receipt, depositContractAddr common.Address) ([]*types.DepositTx, error) { 17 | var out []*types.DepositTx 18 | var result error 19 | for i, rec := range receipts { 20 | if rec.Status != types.ReceiptStatusSuccessful { 21 | continue 22 | } 23 | for j, log := range rec.Logs { 24 | if log.Address == depositContractAddr && len(log.Topics) > 0 && log.Topics[0] == DepositEventABIHash { 25 | dep, err := UnmarshalDepositLogEvent(log) 26 | if err != nil { 27 | result = multierror.Append(result, fmt.Errorf("malformatted L1 deposit log in receipt %d, log %d: %w", i, j, err)) 28 | } else { 29 | out = append(out, dep) 30 | } 31 | } 32 | } 33 | } 34 | return out, result 35 | } 36 | 37 | 实际是有协程一直在做这个事 38 | 39 | ``` 40 | 41 | sequencer 从L1中获取到质押事件，再将其组成质押交易，同时构造attr(需要详细了解），然后将这些必要数据提交给引擎来构建包含attr的区块。StartPayload 42 | 43 | ConfirmPayload 完成块的构建， 搞了半天构建区块都是seqencer在干， payload 就是区块，sequncer 最终也会调用finalizeAndAssemble,就是不清楚是走的l2的哪个共识引擎。 44 | 45 | sequencer组装完毕后进行发布L2payload,通过Op-node 的gossip功能发布到本地，通过channel s.unsafeL2Payloads，来接收，最后扔到一个engine_equeqe 队列里了， 接着执行 reqStep() 46 | 47 | sequencer实际是要从L1获取质押事件，并将交易在L2执行，并打包到区块中。 48 | 49 | 50 | 51 | 接下来batcher submitter登场： 他会定期从L2区块中将交易数据以打包的形式组装到交易 并提交到合约中 52 | 53 | batch submitter 走的是op-batcher的组件，需要l2,l1,rollup-node 的客户端信息 54 | 55 | ```go 56 | // 他会有个轮询间隔，会将L2状态信息（交易）提交给L1 57 | func (l *BatchSubmitter) publishStateToL1(queue *txmgr.Queue[txData], receiptsCh chan txmgr.TxReceipt[txData], drain bool) { 58 | l.sendTransaction(txdata, queue, receiptsCh) 59 | } 60 | 61 | 62 | ``` 63 | 64 | 这个后面会发交易提到BatchInboxAddress， 65 | 66 | Op-proposer 提交proof 到l200contractx x x 地址，然后就等待挑战期了。 67 | 68 | o p-geth 保存了完整的状态数据 69 | 70 | 71 | 72 | 将L2交易收到后再提交给L1，然后得到L1 执行的receipt，进行处理，结束，那么问题是L1 执行完干嘛呢？？？ 73 | 74 | op-geth 应该是proposer 要执行的 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | -------------------------------------------------------------------------------- /DApp_Development/合约基础/solidity_selector.md: -------------------------------------------------------------------------------- 1 | ### 什么是 Solidity selector？ 2 | 3 | 在 Solidity 中，函数参数和名称的组合将构成一个确定的 Solidity 函数标识符，称之为 Solidity selector 或 funchash。Solidity selector 在函数调用时起到了关键作用，作为函数的「指纹」标识符，确保在 Solidity 合约中唯一识别每个函数。如果两个函数参数和名称的组合相同但返回类型不同，则它们会有不同的 Solidity selector。 4 | 5 | Solidity selector 是一个将函数的参数和名称 Hash 运算后得到的 4 字节的标识符。它是所有 Solidity 函数的独特标识，它唯一标识了所有函数的调用签名。我们可以使用 Solidity 中的 `selector` 关键字来获取一个 Solidity 函数的 selector。 6 | 7 | ### Solidity selector 的语法 8 | 9 | Solidity selector 是由函数的标识构成的 32 位十六进制值。在 Solidity 中，我们可以使用 `bytes4` 类型来表示 Solidity selector。具体语法如下： 10 | 11 | ``` 12 | function myFunction(uint256 _param1, address _param2) public returns (uint256) { 13 | // 函数体 14 | } 15 | 16 | bytes4 selector = myFunction.selector; 17 | ``` 18 | 19 | 在上面的代码中，我们定义了一个名为 `myFunction` 的 Solidity 函数。在第 5 行，我们使用了 `.selector` API 获取了函数 `myFunction` 的 Solidity selector。 20 | 21 | ### Solidity selector 的使用 22 | 23 | 在 Solidity 合约开发中，我们通常会使用 Solidity selector 来将函数的数据传递给其他合约或外部项目。Solidity selector 可以通过以下两种方式使用。 24 | 25 | #### 1. 将 Solidity selector 传递给其他合约 26 | 27 | 当我们将 Solidity 写的合约作为一个子合约部署到网络上时，其他合约可以使用该合约的函数，这意味着其他合约需要知道该函数的 Solidity selector 才能正确地调用该函数。例如，考虑如下的 Solidity 合约： 28 | 29 | ``` 30 | contract myContract { 31 | function myFunction(uint256 _param1, address _param2) public returns (uint256) { 32 | // 函数体 33 | } 34 | } 35 | ``` 36 | 37 | 在上述合约中，我们观察到 `myFunction` 函数的 Solidity selector 可以通过代码 `myFunction.selector` 获取，我们在其他合约中需要使用它来正确调用上述 solidity 合约中的函数。 38 | 39 | #### 2. Solidity selector 的使用方式 40 | 41 | 另一种常见的 Solidity selector 的使用方式是作为某些外部调用或函数调用的参数，如 `external_call(selector, data)` 和 `bytes4 data = myFunction.selector` 等。例如： 42 | 43 | ``` 44 | contract AnotherContract { 45 | address public myContractAddress = 0x123abc... 46 | 47 | function foo() public returns (uint256) { 48 | bytes4 selector = bytes4(keccak256(bytes("myFunction(uint256,address)"))); 49 | // 使用 Solidity selector 调用 myFunction 函数 50 | (bool success, bytes memory result) = myContractAddress.call(abi.encodeWithSelector(selector, 123, 0x456)); 51 | // 解析结果数据，在 result 数组的索引为 0 处有返回值，该返回值是 uint256 类型。 52 | uint256 returnValue = abi.decode(result, (uint256)); 53 | return returnValue; 54 | } 55 | } 56 | ``` 57 | 58 | ### Solidity selector 的重要性 59 | 60 | 在 Solidity 中，Solidity selector 扮演了非常关键的角色。作为函数调用的签名和「指纹」，Solidity selector 确保在 Solidity 合约中唯一标识每个函数，从而帮助避免代码混淆和错误的函数调用。此外，Solidity selector 还提供了函数调用的安全性，确保函数参数的正确性和完整性。 61 | 62 | 总之，Solidity selector 作为 Solidity 中非常重要的概念和语法，是 Solidity 开发人员必须理解和掌握的。掌握 Solidity selector 将使您更加熟练地开发智能合约，并能够在 Solidity 合约中正确地识别和调用函数。 -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/arbitrum/sequencer.md: -------------------------------------------------------------------------------- 1 | ## 定序器和审查阻力 2 | 3 | Sequencer是专门指定的Arbitrum全节点，在正常情况下，负责将用户的交易提交到L2。原则上，链的 Sequencer 可以采用不同的形式；正如 Arbitrum One 目前的情况，Sequencer 是一个单一的、集中的实体；最终，排序功能将提供给一个分布式排序委员会，该委员会就排序达成共识。然而，无论其形式如何，Sequencer 都有一个不适用于系统任何其他部分的基本限制：它必须在自己的安全假设下运行；也就是说，原则上，它不能直接从第 1 层获得安全性。这就提出了一个问题，即当 Sequencer 行为不当时，Arbitrum Rollup 如何保持其抗审查性的主张。 4 | 5 | 在这里，我们将描述 Sequencer 通常如何运行的机制，以及任何用户如何完全绕过 Sequencer 直接从第 1 层提交任何 Arbitrum 交易（包括启动 L2 到 L1 消息以提取资金的交易）。因此因此，即使 Sequencer 完全没有响应甚至是恶意的，该机制也能保持审查抵抗力。 6 | 7 | ## 核心收件箱 8 | 9 | 当我们谈论“将交易提交到 Arbitrum 链中”时，我们是在谈论将其包含到链的核心收件箱中，由 Bridge 中的 sequencerInboxAccs 字节数组表示。一旦交易被包含在核心收件箱中，它们的顺序是固定的，执行是完全确定的，我们可以不信任地将结果状态视为具有 L1 级最终性（参见“交易生命周期”）。 Sequencer 的角色（或缺乏角色）严格关注之前发生的事情；即，交易如何进入核心收件箱。我们将把交易可能采用的路由分为两种情况：行为良好的 Sequencer 和有故障的 Sequencer。 10 | 11 | ## 快乐/常见案例：Sequencer 已上线且表现良好 12 | 13 | 在这里，我们首先假设 Sequencer 是完全可操作的，并且以尽可能安全和及时的方式处理用户交易的目的运行。 Sequencer 可以通过两种方式接收用户的交易——直接通过 RPC 请求，或通过底层 L1。 14 | 15 | 如果用户发布“标准”Arbitrum 交易（即与 L2 原生 dapp 交互），用户将直接向 Sequencer 提交已签名的交易，就像用户在与 L1 交互时向以太坊节点提交交易一样.收到它后，Sequencer 将执行它并几乎立即向用户发送收据。不久之后——通常不超过几分钟——Sequencer 将把用户的交易包含在一个批次中，并通过调用 SequencerInbox 的 addSequencerL2Batch 方法之一将其发布到 L1 上。请注意，只有 Sequencer 才有权调用这些方法；事实上，这种任何其他方都不能直接包含消息的保证正是赋予 Sequencer 提供即时“软确认”收据的独特能力的关键所在。一旦成批发布，交易就具有 L1 级最终确定性。 16 | 17 | 或者，用户可以通过将其发布到底层 L1 上来将其 L2 消息提交给 Sequencer。如果用户希望与 L2 消息一起执行一些 L1 操作并保持两者之间的原子性，则此路径是必需的——这里的教科书示例是通过桥接的代币存款（在 L1 上托管，在 L2 上铸币）。用户通过发布调用收件箱合约上相关方法之一的 L1 交易（即向 L1 节点发送普通交易）来实现此目的；即，sendUnsignedTransaction。这会在我们称之为“延迟收件箱”的地方添加一条消息（由 Bridge 合约中的 delayedInboxAccs 表示），这实际上是一个队列，消息在被移至核心收件箱之前等待。 Sequencer 将在交易被包含在延迟的收件箱中约 10 分钟后发出 L2 收据（延迟的原因是为了最大限度地减少短期 L1 重组的风险，这可能会导致 L2 重组并使 Sequencer 的 L2 无效收据。）同样，最后一步是 Sequencer 将 L2 消息包含在批处理中——当调用批处理提交方法时，Sequencer 指定延迟收件箱中要包含的消息数——完成交易。 18 | 19 | 总而言之——无论哪种情况，用户首先将他们的消息传递给 Sequencer，Sequencer 确保消息到达核心收件箱。 20 | 21 | ## 不愉快/不常见的情况：Sequencer 没有完成它的工作 22 | 23 | 现在让我们假设 Sequencer，无论出于何种原因，完全无法执行其提交消息的任务。用户仍然可以通过两个步骤获得他们的交易： 24 | 25 | 首先，他们如上所述通过 L1 将 L2 消息提交到延迟收件箱：请注意，尽管原子跨链消息是使用延迟收件箱的常见情况，但原则上它可以用于提交任何 L2 消息。 26 | 27 | 一旦进入延迟收件箱，我们显然不能依赖 Sequencer 将交易包含在批处理中。相反，我们可以使用 SequencerInbox 的 forceInclusion 方法。一旦消息在延迟收件箱中停留了足够长的时间，就可以调用 forceInclusion 将其从延迟收件箱移动到核心收件箱中，此时它已完成。至关重要的是，任何帐户都可以调用 forceInclusion。 28 | 29 | 目前，在 Arbitrum One 上，提交和强制包含之间的延迟时间大约为 24 小时，由 maxTimeVariation.delayBlocks / maxTimeVariation.delaySeconds 指定。来自 L1 的强制包含将直接影响任何未确认的 L2 交易的状态；保持保守的高延迟值确保它只应在特殊情况下使用。 30 | 31 | 除了延迟本身之外，forceInclusion 路径还存在交易排序不确定性的缺点；即，在等待消息的最大延迟通过时，恶意的 Sequencer 原则上可以直接在它前面发布消息。然而，Sequencer 最终无法阻止它被包含在核心收件箱中，此时它的排序已经完成。 32 | 33 | 虽然缓慢、“不愉快”的路径不是最优的，而且很少（如果有的话）是必要的，但它作为一个选项的可用性确保 Arbitrum Rollup 始终保留其不信任的安全模型，即使系统的许可部分出现故障也是如此。 -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism spec分析/op-rollupnode.md: -------------------------------------------------------------------------------- 1 | # 汇总节点规范 2 | 3 | [Rollup 节点](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#rollup-node)是负责从 L1 区块（及其关联的[收据）](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#receipt)[派生 L2 链的](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#L2-chain-derivation)组件。 4 | 5 | Rollup 节点中派生 L2 链的部分称为[rollup 驱动程序](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#rollup-driver)。本文档目前仅涉及 rollup 驱动程序的规范。 6 | 7 | **目录** 8 | 9 | - 司机 10 | - [推导](https://github.com/ethereum-optimism/optimism/blob/develop/specs/rollup-node.md#derivation) 11 | - L2输出RPC方法 12 | - [输出方法API](https://github.com/ethereum-optimism/optimism/blob/develop/specs/rollup-node.md#output-method-api) 13 | 14 | ## 司机 15 | 16 | [Rollup 节点](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#rollup-node)中的[driver](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#rollup-driver)的任务 是管理[派生](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#L2-chain-derivation)过程： 17 | 18 | - 跟踪 L1 头块 19 | - 跟踪L2链同步进度 20 | - 当新输入可用时迭代推导步骤 21 | 22 | ### 推导 23 | 24 | 此过程分三个步骤进行： 25 | 26 | 1. 从最后一个 L2 区块顶部的 L1 链中选择输入：区块列表，包含交易以及相关数据和收据。 27 | 2. 读取 L1 信息、存款和排序批次，以生成有效[负载属性](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#payload-attributes) （本质上[是没有输出属性的块](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#block)）。 28 | 3. 将有效负载属性传递给[执行引擎](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#execution-engine)，以便可以计算L2块（包括[输出块属性）。](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#block) 29 | 30 | 虽然这个过程在概念上是从 L1 链到 L2 链的纯函数，但实际上是增量的。每当新的 L1 块添加到 L1 链时，L2 链就会扩展。类似地，每当 L1 链重新组织时，L2 链也会[重新组织](https://github.com/ethereum-optimism/optimism/blob/develop/specs/glossary.md#re-organization)。 31 | 32 | 有关 L2 块推导的完整规范，请参阅[L2 块推导文档](https://github.com/ethereum-optimism/optimism/blob/develop/specs/derivation.md)。 33 | 34 | ## L2输出RPC方法 35 | 36 | Rollup 节点有自己的 RPC 方法，`optimism_outputAtBlock`该方法返回与[L2 输出 root](https://github.com/ethereum-optimism/optimism/blob/develop/specs/proposals.md#l2-output-commitment-construction)对应的 32 字节哈希。 37 | 38 | ### 输出方法API 39 | 40 | 这里的输入和返回类型是由[引擎 API 规范](https://github.com/ethereum/execution-apis/blob/main/src/engine/paris.md#structures)定义的）。 41 | 42 | - 方法：`optimism_outputAtBlock` 43 | - 参数： 44 | 1. `blockNumber`: `QUANTITY`, 64 位 - L2 整数块号 45 | OR - 、、 或`String`之一。`"safe"``"latest"``"pending"` 46 | - 返回： 47 | 1. `version`: `DATA`, 32 字节 - 输出根版本号，从 0 开始。 48 | 2. `l2OutputRoot`: `DATA`, 32 字节 - 输出根。 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/基础/对称加密.md: -------------------------------------------------------------------------------- 1 | # 对称加密 2 | 3 | 对称加密是一种密码学技术，它使用相同的密钥进行加密和解密操作。相较于非对称加密，对称加密速度较快，但在密钥管理和分发方面存在一定的挑战。以下是对对称加密的详细介绍。 4 | 5 | ## 什么是对称加密？ 6 | 7 | 对称加密算法使用**单一密钥**对数据进行加密和解密。**发送方和接收方需要共享相同的密钥**，以确保安全通信。这种加密方法的优点是处理速度快，适用于大量数据的加密。然而，由于**双方需要共享密钥，因此在密钥分发和管理方面存在风险**。 8 | 9 | ## 对称加密的类型 10 | 11 | 对称加密算法主要分为两类： 12 | 13 | 1. **流加密（Stream Cipher）**：流加密是一种逐位处理明文的加密方法。它使用伪随机数生成器（PRNG）生成密钥流，然后通过异或操作将密钥流与明文结合以生成密文。流加密适用于不可预测长度的数据流，但可能存在安全隐患。常见的流加密算法包括RC4、Salsa20和ChaCha20等。 14 | 2. **块加密（Block Cipher）**：块加密是将明文分成固定长度的块，然后对每个块进行加密。这类加密算法通常使用多轮加密操作，包括替换（Substitution）、置换（Permutation）和混淆（Confusion）等步骤。块加密适用于已知长度的数据，如文件加密。常见的块加密算法包括AES、DES和3DES等。 15 | 16 | ## 常见的对称加密算法 17 | 18 | 以下是一些常见的对称加密算法： 19 | 20 | - **AES（Advanced Encryption Standard）**：AES是美国国家标准与技术研究院（NIST）认可的对称加密标准。AES支持128、192和256位密钥长度，使用128位数据块。AES具有高安全性和良好的性能，广泛应用于各种场景。 21 | 22 | - **DES（Data Encryption Standard）**：DES是一种曾经广泛使用的对称加密标准，使用56位密钥和64位数据块。由于其密钥长度较短，DES容易受到暴力破解攻击，目前已被AES替代。 23 | 24 | - **3DES（Triple DES）**：3DES是DES的扩展版本，通过对数据进行三次DES加密以增强安全性。3DES使用两个或三个不同的56位密钥，相当于112位或168位密钥长度。然而，3DES的加密效率较低，逐渐被AES取代。 25 | 26 | - **Blowfish**：Blowfish是一种可变密钥长度的对称加密算法，密钥长度可以从32位到448位。它使用64位数据块并具有高安全性和性能。但在处理大量数据时，Blowfish的加密速度较慢。 27 | - **Twofish**：Twofish是Blowfish的后继者，使用128位数据块和可变密钥长度（128、192和256位）。Twofish具有良好的安全性和性能，适用于各种场景。 28 | - **RC4**：RC4是一种流加密算法，具有简单的结构和快速的加密速度。然而，RC4存在一定的安全隐患，已被Salsa20和ChaCha20等更安全的流加密算法替代。 29 | - **Salsa20/ChaCha20**：Salsa20和ChaCha20是两种高性能流加密算法，它们具有相似的结构，但使用不同的轮函数。这两种算法使用256位密钥，具有高安全性和良好的性能。它们已经逐渐取代RC4成为新一代流加密算法的首选。 30 | 31 | ## 密钥管理与分发 32 | 33 | 在对称加密中，密钥管理和分发是关键。发送方和接收方需要共享相同的密钥，以保证通信的安全性。但密钥分发存在一定的风险，因为在传输过程中，密钥可能被窃取。 34 | 35 | 为解决密钥分发问题，通常采用以下方法： 36 | 37 | - **密钥协商**：通过Diffie-Hellman密钥交换、Elliptic Curve Diffie-Hellman（ECDH）等算法，在双方之间安全地生成共享密钥。 38 | - **密钥传输**：使用非对称加密算法（如RSA）对密钥进行加密传输。接收方使用其私钥解密以获取对称加密密钥。 39 | 40 | 对称加密在许多现实应用中发挥着重要作用，如TLS/SSL安全通信、磁盘加密和文件加密等。了解对称加密的基本原理和常见算法，有助于我们更好地理解和使用加密技术保护数据安全。 41 | 42 | ## 对称加密与其他加密技术的结合 43 | 44 | 对称加密算法虽然在加密速度和性能方面具有优势，但在密钥管理和分发方面存在挑战。因此，通常将对称加密与其他加密技术（如非对称加密和哈希函数）结合使用，以实现更高的安全性和可用性。 45 | 46 | 1. **混合加密（Hybrid Encryption）**：混合加密结合了对称加密和非对称加密的优点。在通信过程中，使用非对称加密算法安全地传输对称加密密钥，然后使用对称加密算法加密实际数据。这样，既保证了通信的安全性，又提高了加密效率。混合加密广泛应用于TLS/SSL等安全通信协议。 47 | 2. **加密认证（Authenticated Encryption）**：加密认证结合了加密和消息认证码（Message Authentication Code, MAC）技术，以确保数据的机密性、完整性和真实性。常见的加密认证模式包括Galois/Counter Mode（GCM）和Counter with CBC-MAC（CCM）。它们使用对称加密算法（如AES）进行加密，同时使用哈希函数生成消息认证码。 48 | 3. **安全多方计算（Secure Multi-Party Computation, SMPC）**：安全多方计算是一种密码学技术，允许多个参与者在不泄露各自数据的情况下共同计算一个函数。SMPC通常结合对称加密、非对称加密和零知识证明等技术，以实现数据隐私和计算安全。 49 | 50 | 通过将对称加密与其他加密技术相结合，我们可以在保证数据安全的同时，充分利用各种加密技术的优点，实现高效和可靠的加密通信。 51 | 52 | 总之，对称加密作为密码学的一种基本技术，具有快速、高效的加密性能，但在密钥管理和分发方面存在一定的挑战。为了克服这些挑战，我们通常将对称加密与其他加密技术结合使用，如非对称加密、哈希函数等。了解对称加密的原理和常见算法，将有助于我们在实际应用中更好地利用加密技术来保护数据和通信安全。 -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism源码分析/死磕optimism之withdraw.md: -------------------------------------------------------------------------------- 1 | 用户从L2StandardBridge.sol 提现 2 | 3 | ```solidity 4 | function withdraw( 5 | address _l2Token, 6 | uint256 _amount, 7 | uint32 _minGasLimit, 8 | bytes calldata _extraData 9 | ) external payable virtual onlyEOA { 10 | _initiateWithdrawal(_l2Token, msg.sender, msg.sender, _amount, _minGasLimit, _extraData); 11 | } 12 | 13 | function _initiateWithdrawal( 14 | address _l2Token, 15 | address _from, 16 | address _to, 17 | uint256 _amount, 18 | uint32 _minGasLimit, 19 | bytes memory _extraData 20 | ) internal { 21 | if (_l2Token == Predeploys.LEGACY_ERC20_ETH) { 22 | _initiateBridgeETH(_from, _to, _amount, _minGasLimit, _extraData); 23 | } else { 24 | address l1Token = OptimismMintableERC20(_l2Token).l1Token(); 25 | _initiateBridgeERC20(_l2Token, l1Token, _from, _to, _amount, _minGasLimit, _extraData); 26 | } 27 | } 28 | 29 | 30 | function _initiateBridgeERC20( 31 | address _localToken, 32 | address _remoteToken, 33 | address _from, 34 | address _to, 35 | uint256 _amount, 36 | uint32 _minGasLimit, 37 | bytes memory _extraData 38 | ) internal { 39 | if (_isOptimismMintableERC20(_localToken)) { 40 | require( 41 | _isCorrectTokenPair(_localToken, _remoteToken), 42 | "StandardBridge: wrong remote token for Optimism Mintable ERC20 local token" 43 | ); 44 | 45 | OptimismMintableERC20(_localToken).burn(_from, _amount); 46 | } else { 47 | IERC20(_localToken).safeTransferFrom(_from, address(this), _amount); 48 | deposits[_localToken][_remoteToken] = deposits[_localToken][_remoteToken] + _amount; 49 | } 50 | 51 | // Emit the correct events. By default this will be ERC20BridgeInitiated, but child 52 | // contracts may override this function in order to emit legacy events as well. 53 | _emitERC20BridgeInitiated(_localToken, _remoteToken, _from, _to, _amount, _extraData); 54 | 55 | MESSENGER.sendMessage( 56 | address(OTHER_BRIDGE), 57 | abi.encodeWithSelector( 58 | this.finalizeBridgeERC20.selector, 59 | // Because this call will be executed on the remote chain, we reverse the order of 60 | // the remote and local token addresses relative to their order in the 61 | // finalizeBridgeERC20 function. 62 | _remoteToken, 63 | _localToken, 64 | _from, 65 | _to, 66 | _amount, 67 | _extraData 68 | ), 69 | _minGasLimit 70 | ); 71 | } 72 | ``` 73 | 74 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/密码学中的数学/密码学中的数学基础.md: -------------------------------------------------------------------------------- 1 | # 数论基础 2 | 3 | - **1. 整数和除法** 4 | - [x] : 最基本的整数概念 5 | - [x] : 整数除法 6 | - [x] : 最大公约数（GCD） 7 | - [x] : 最小公倍数（LCM） 8 | - **2. 素数和素数分布** 9 | - [x] : 素数的定义和性质 10 | - 素数筛法（如埃拉托斯特尼筛法） 11 | - 素数分布的理论和猜想（如素数定理） 12 | 13 | - **3. 模运算** 14 | - [x] : 模运算的定义和性质 15 | - [x] : 逆元 16 | - [x] : 模运算的应用 17 | - **4. 同余** 18 | - [x] : 同余的定义和性质 19 | - [x] : 同余的运算法则 20 | - [x] : 同余方程 21 | - **5. 费马小定理和欧拉定理** 22 | - [ ] : 费马小定理的陈述、证明和应用 （群的理论） 23 | - [ ] : 欧拉定理的陈述、证明和应用 24 | - **6. 线性同余方程** 25 | - 解线性同余方程的方法 26 | - 扩展欧几里得算法 27 | - 中国剩余定理 28 | - **7. 欧几里得算法** 29 | - 欧几里得算法用于计算最大公约数 30 | - 扩展欧几里得算法用于求解线性丢番图方程 31 | - **8. Wilson定理和其他数论定理** 32 | - Wilson定理及其应用 33 | - 孙子定理等其他数论定理 34 | - **9. 算术函数** 35 | - 欧拉ϕ函数 36 | - 莫比乌斯函数 37 | - 其他数论函数的性质和应用 38 | - **10. 二次剩余和二次互素** 39 | - 二次剩余的定义和性质 40 | - Legendre符号和Jacobi符号 41 | - 解二次同余方程的方法 42 | - **11. 不定方程** 43 | - 丢番图方程 44 | - 佩尔方程 45 | - 其他整数解的不定方程 46 | - **12. 连分数** 47 | - 连分数的定义和性质 48 | - 连分数在数论中的应用，如求解最佳有理逼近 49 | - **13. 概率数论** 50 | - 整数性质的概率分布 51 | - 随机整数的算术性质 52 | - 概率数论中的其他分布和性质 53 | - **14.数论的几何和代数方法** 54 | - 椭圆曲线在数论中的应用 55 | - 代数数域 56 | - 代数几何方法在数论问题中的应用 57 | 58 | 这是一个完整的数论学习大纲，涵盖了数论的主要内容。根据自己的兴趣和需求，您可以有选择地深入研究某些主题。对于密码学和计算机科学背景的学习者来说，同余、模运算、费马小定理、欧拉定理等主题尤为重要。 59 | 60 | # 代数基础 61 | 62 | - **1. 基本概念和运算** 63 | - [x] 实数、复数、有理数和无理数 64 | - [x] 四则运算、指数和对数运算 65 | - [x] 集合、关系和映射 66 | - **2. 代数式和多项式** 67 | - [x] 代数式的基本概念 68 | - [x] 多项式及其运算 69 | - [x] 因式分解 70 | - [x] 多项式的零点和根 71 | - **3. 线性代数** 72 | - 向量空间和基底 73 | - 矩阵运算和线性方程组 74 | - 行列式和逆矩阵 75 | - 特征值和特征向量 76 | - 线性变换和相似矩阵 77 | - 奇异值分解和主成分分析 78 | - **4. 代数方程和代数方程组** 79 | - 一元代数方程的解法 80 | - 高次代数方程的解法 81 | - 系数和根之间的关系 82 | - 代数方程组的解法 83 | - 线性方程组的解法和应用 84 | - **5. 群、环和域** 85 | - [x] 群的定义、性质和分类 86 | - 拓扑群和李群 87 | - 环的定义、性质和分类 88 | - [x] 域的定义、性质和分类 89 | - [x] 有限域及其在密码学中的应用 90 | - **6. 抽象代数** 91 | - 同态和同构 92 | - 正规子群和正规子环 93 | - 群表征和表示论 94 | - Galois理论和代数扩张 95 | - **7. 代数几何** 96 | - 仿射空间和射影空间 97 | - 代数曲线和椭圆曲线 98 | - 代数簇和概型 99 | - 奇点和奇点消解 100 | - **8. 数论和代数** 101 | - 整数环和整数域 102 | - 代数数和代数数域 103 | - 理想和整环 104 | - **9.多元代数** 105 | - 多元多项式 106 | - Groebner基和多项式理想 107 | - 多元多项式的应用（如多元方程组求解） 108 | - **10. 向量空间的几何解释** 109 | - 向量及其几何表示 110 | - 线性无关和线性相关 111 | - 子空间、基和维数 112 | - 正交性和正交基 113 | - **11. 二次型和Jordan标准形** 114 | - 二次型的定义和性质 115 | - 二次型的规范形 116 | - Jordan标准形的定义和性质 117 | - 计算Jordan标准形的方法 118 | - **12. 模型论和一阶逻辑** 119 | - 一阶逻辑的基本概念 120 | - 模型论的基本概念 121 | - Gödel不完备性定理 122 | 123 | 这个大纲涵盖了代数的主要内容。学习代数时，您可以根据自己的兴趣和需求有选择地深入研究某些主题。对于密码学和计算机科学背景的学习者来说，线性代数、群、环和域以及有限域等主题尤为重要。 -------------------------------------------------------------------------------- /DApp_Development/应用场景/defi/uniswap/v2/uniswap_v2_Factory.md: -------------------------------------------------------------------------------- 1 | > 基于ee547b17853e71ed4e0101ccfd52e70d5acded58 2 | > 3 | > [Uniswap/v2-periphery: 🎚 Peripheral smart contracts for interacting with Uniswap V2 (github.com)](https://github.com/Uniswap/v2-periphery) 4 | > 5 | > [Uniswap/v2-core: 🎛 Core smart contracts of Uniswap V2 (github.com)]( 6 | 7 | 8 | 9 | ## 概述 10 | 11 | UniswapV2Factory合约用来创建资金池，其主要有以下几方面内容： 12 | 13 | - 如何创建交易对 14 | - 如何管理收费地址 15 | - 如何查询交易对信息 16 | 17 | ----- 18 | 19 | ## 创建交易对 20 | 21 | 通过工厂模式来创建新的资金池合约，并返回资金池地址。每个交易对都会有相应的合约。 22 | 23 | ```solidity 24 | function createPair(address tokenA, address tokenB) external returns (address pair) { 25 | // 要求 tokenA 和 tokenB 地址不相等 26 | require(tokenA != tokenB, 'UniswapV2: IDENTICAL_ADDRESSES'); 27 | 28 | // 根据地址大小排序，确保唯一性 29 | (address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA); 30 | require(token0 != address(0), 'UniswapV2: ZERO_ADDRESS'); 31 | 32 | // 要求交易对不存在 33 | require(getPair[token0][token1] == address(0), 'UniswapV2: PAIR_EXISTS'); 34 | 35 | // 获取 UniswapV2Pair 合约的字节码 36 | bytes memory bytecode = type(UniswapV2Pair).creationCode; 37 | 38 | // 使用参数 token0, token1 计算 salt 39 | bytes32 salt = keccak256(abi.encodePacked(token0, token1)); 40 | assembly { 41 | // 使用 create2 部署 Pair 合约 42 | pair := create2(0, add(bytecode, 32), mload(bytecode), salt) 43 | } 44 | 45 | // Pair 合约初始化 46 | IUniswapV2Pair(pair).initialize(token0, token1); 47 | 48 | // 记录 token0,token1 创建的资金池地址是 pair 49 | getPair[token0][token1] = pair; 50 | getPair[token1][token0] = pair; // 以相反顺序也存储交易对地址，方便查询 51 | allPairs.push(pair); 52 | emit PairCreated(token0, token1, pair, allPairs.length); 53 | } 54 | ``` 55 | 56 | 57 | 58 | ## 管理收费地址 59 | 60 | ```solidity 61 | function setFeeTo(address _feeTo) external { 62 | require(msg.sender == feeToSetter, 'UniswapV2: FORBIDDEN'); 63 | feeTo = _feeTo; 64 | } 65 | 66 | function setFeeToSetter(address _feeToSetter) external { 67 | require(msg.sender == feeToSetter, 'UniswapV2: FORBIDDEN'); 68 | feeToSetter = _feeToSetter; 69 | } 70 | ``` 71 | 72 | `feeTo` 和 `feeToSetter` 是两个与交易手续费相关的地址： 73 | 74 | 1. `feeTo`：这是接收交易手续费的地址。在 Uniswap V2 中，每次发生交易时，会产生一定比例的手续费。这些手续费的一部分会作为激励分配给流动性提供者，另一部分会发送给 `feeTo` 地址。通常，这个地址会被设置为一个特定的项目或组织（用于支持项目发展、激励生态系统） 75 | 76 | 2. `feeToSetter`：这是一个具有权限的地址，负责设置 `feeTo` 地址。`feeToSetter` 可以调用 `setFeeTo()` 函数来更改 `feeTo` 地址。在 `UniswapV2Factory` 合约的构造函数中，`feeToSetter` 默认被设置为合约部署者的地址（一般团队控制）。此外，`feeToSetter` 也可以调用 `setFeeToSetter()` 函数来转移这个权限给另一个地址。 77 | 78 | 之所以只允许 `feeToSetter` 来调用这些函数，是为了确保对手续费分配的控制权只能由具有相应权限的地址进行操作。这样可以防止恶意用户修改手续费接收地址或滥用权限。同时，这种设计也允许项目方或组织方灵活地设置和更改手续费接收地址，以满足不同的需求。 -------------------------------------------------------------------------------- /Public_Chain_Development/P2P_Network/p2p/死磕libp2p之传输.md: -------------------------------------------------------------------------------- 1 | # listen&dial 2 | 3 | ## 通用传输接口 4 | 5 | 传输是根据两个核心操作来定义的，即监听和拨号。 6 | 7 | 侦听意味着您可以使用传输实现提供的任何功能来**接受来自其他对等方的传入连接**。例如，unix平台上的TCP传输可以使用绑定和侦听系统调用，让操作系统将给定TCP端口上的流量路由到应用程序。 8 | 9 | 拨号是打开与侦听对等方的传出连接的过程。与监听一样，具体内容由实现决定，但libp2p实现中的每个传输都将共享相同的编程接口。 10 | 11 | ## 地址 12 | 13 | 在建立对peer的拨号连接之前，我们需要知道如何访问这些peer。由于每种传输方式会有其独特的寻址方案，因此libp2p采用了一种称为“Multiaddress”或“Multiaddr”的协议来编码许多不同的寻址方案。 14 | 15 | 下面是一个针对TCP/IP传输的Multiaddr示例： 16 | 17 | ```markdown 18 | /ip4/198.51.100.0/tcp/6543 19 | ``` 20 | 21 | 这与更常见的“198.51.100.0: 6543”写法是等价的，但它具有显式说明所涉及协议的优势。通过Multiaddr，您可以一目了然地看出198.51.100.0地址属于IPv4协议，而6543则属于TCP协议 22 | 23 | “dial”和“listen”都涉及Multiaddress。在**监听时，您向传输层提供您要监听的地址**，在**拨打对等端时，则需要提供将要拨打的地址**。 24 | 25 | 在拨打远程对等节点时，Multiaddress应包括您想要连接的对等节点的Peer ID。这使libp2p能够建立安全通信通道并防止身份伪装。 26 | 27 | 下面是一个包含Peer ID的Multiaddress示例： 28 | 29 | ```markdown 30 | /ip4/192.0.2.0/tcp/4321/p2p/QmcEPrat8ShnCph8WjkREzt5CPXF2RwhYxYBALDcLC1iV6 31 | ``` 32 | 33 | 其中的“/p2p/QmcEPrat8ShnCph8WjkREzt5CPXF2RwhYxYBALDcLC1iV6”组件使用公钥的哈希唯一地标识了远程对等节点 34 | 35 | ## 支持多个传输 36 | 37 | libp2p应用程序**通常需要同时支持多个传输方式**。例如，您可能希望您的服务可以通过TCP从长时间运行的守护进程使用，同时也可以接受来自在Web浏览器中运行的对等节点的WebSocket连接。 38 | 39 | 负责管理多种传输方式的libp2p组件称为“switch”，它还协调协议协商、流多路复用、建立安全通信以及其他形式的“连接升级”。 40 | 41 | switch提供了单个“入口点”进行拨号和监听，使您的应用程序代码无需担心特定的传输方式和其他底层使用的“连接堆栈”组件。 42 | 43 | 可以将它看作是一个高级接口，可以让我们更轻松地编写支持多种传输方式的复杂应用程序，并且无需深入了解底层实现细节 44 | 45 | # QUIC 46 | 47 | QUIC是一种新的传输协议，它提供了一种建立在UDP之上的始终加密的流复用连接 48 | 49 | ## TCP关键挑战 50 | 51 | Head-of-line blocking (HoL)：当一个数据包在传输过程中被丢失时，后续的数据包需要等待该数据包重传后才能被传输，这样就导致了传输的阻塞。因为TCP是基于**字节流**传输的，数据包之间没有明确的边界，所以即使只有一个数据包丢失，后面的数据也需要等待该数据包的重传，这样就会导致后面的数据包无法及时到达接收方，从而增加了延迟和拥塞。 52 | 53 | Ossification：由于TCP的协议头不加密，中间节点可以检查和修改TCP协议头字段，当它们遇到任何不理解的字段时可能对TCP协议破坏，这使得更改TCP协议的任何线路格式变得几乎不可能。 54 | 55 | 握手效率低下：TCP花费一次网络往返时间（RTT）来验证客户端的地址。只有在此之后，TLS才能开始密码握手，再消耗一次RTT。因此，建立加密连接始终需要两个RTTs。 56 | 57 | QUIC的设计考虑了以下目标： 58 | 59 | - 流传输不会导致Head-of-line blocking (HoL)问题，因为在流传输中，数据是被划分为**多个数据流**（stream）并独立传输的。每个数据流都有自己的编号，并且数据包里面带有数据流的编号信息，接收方可以根据数据流的编号把数据包放到正确的数据流中，从而避免了传输过程中的Head-of-line blocking问题 60 | 61 | - 将连接建立的延迟时间**降至单个RTT**，以允许为恢复的连接发送零RTT应用程序数据。 62 | 63 | - 尽可能加密。这消除了ossification的风险，因为中间节点无法读取任何加密的字段。 64 | 65 | ## QUIC怎么工作的 66 | 67 | 它不是基于TCP构建，而是基于UDP构建。当一个UDP数据包丢失时，内核不会自动重传数据包。因此，QUIC负责自行检测和修复丢失的数据包。通过使用加密，QUIC避免了中间节点的强制陈旧。TLS 1.3握手在首个数据包包中完成，省去了验证客户端地址的成本并节省一个RTT。此外，QUIC还暴露多个数据流（而不仅仅是单字节流），因此应用层不需要流多路复用器。部分应用层也直接构建在QUIC中。 68 | 69 | 此外，当客户端已经与某个服务器通信过，可以在后续连接中利用QUIC的0 RTT功能。客户端可以在QUIC握手完成之前就发送（加密的）应用数据 70 | 71 | ## QUIC本机多路复用 72 | 73 | 一个QUIC数据包可以携带来自一个或多个数据流的帧所包含的流数据。由于即使乱序接收，QUIC数据包也可以被解密，这解决了流多路复用器应用于TCP连接时遇到的Head-of-line阻塞问题：如果包含某个流的流数据的数据包丢失，这只会阻塞该流的进展，而所有其他流仍然可以继续前进。 74 | 75 | ## libp2p中的QUIC 76 | 77 | libp2p仅支持双向数据流，同时默认使用TLS 1.3。由于QUIC已经提供了加密的流多路复用连接，libp2p直接使用QUIC数据流，无需任何额外的框架。 78 | 79 | 为了认证各自的对等方ID，节点将自己的对等方ID编码到一个自签名证书中，并使用主机的私钥签名。这与libp2p TLS握手中对等方ID进行认证的方式相同。 80 | 81 | 82 | 83 | -------------------------------------------------------------------------------- /Blockchain_Basics/纠删码.md: -------------------------------------------------------------------------------- 1 | 纠删码（Error-correcting code）是一种通过在原始数据中添加冗余信息来检测和纠正错误的编码方法。纠删码可以应用于许多领域，如数字通信、存储系统和信息理论等。在这篇文章中，我们将介绍纠删码的基本概念、分类以及常见的应用场景。 2 | 3 | ## 一、基本概念 4 | 5 | ### 1. 编码与解码 6 | 7 | 纠删码的核心思想是对原始数据进行编码，在发送和接收端进行解码，实现错误检测和纠正。编码是指将原始数据转换为含有冗余信息的编码数据的过程；解码是指根据接收到的编码数据，从中恢复出原始数据的过程。 8 | 9 | ### 2. 错误控制编码 10 | 11 | 错误控制编码（ECC）是指一类能够检测和纠正存在少量错误的编码技术。ECC包括两种主要类型：前向纠错（FEC）和反向纠错（BEC）。前向纠错技术可以检测并纠正自发生的少量错误；而反向纠错技术则专门用于修复不可避免的大规模错误。 12 | 13 | ### 3. 冗余度与容错性 14 | 15 | 冗余度是指通过添加冗余信息增加的编码数据与原始数据的比例；容错性是指纠删码可以检测和纠正的错误数量。纠删码通常通过增加冗余度来提高容错性。 16 | 17 | ## 二、分类 18 | 19 | ### 1. 块编码与卷积码 20 | 21 | 根据不同的编码方式，纠删码可分为块编码（Block Code）和卷积码（Convolutional Code）两种类型。 22 | 23 | 块编码将指定长度的数据分割成若干个等长的块，每个块进行独立的编码和解码。块编码通常有更高的编码效率，并且计算速度较快。常见的块编码方案包括海明码、RS码和BCH码等。 24 | 25 | 卷积码则是一种流式编码技术，它对连续的原始数据序列进行编码和解码。相比于块编码，卷积码具有更好的抗噪声性能和更高的编解码复杂度。在数字通信领域中，卷积码通常被应用于低信噪比环境下的无线信道传输。常见的卷积码方案包括半无限制和全无限制卷积码等。 26 | 27 | ### 2. 码距 28 | 29 | 码距是指在纠删码中任意两个编码向量之间的汉明距离（Hamming Distance）的最小值。汉明距离是指两个等长字符串之间相应字符不同的位置个数。码距越大，纠删码的容错性就越高，但同时也意味着冗余信息增多。 30 | 31 | ### 3. 线性码与非线性码 32 | 33 | 根据编码方式的不同，纠删码还可以分为线性码（Linear Code）和非线性码（Nonlinear Code）两种类型。 34 | 35 | 在线性码中，任意两个编码向量之和仍然是一个有效的编码向量。这使得线性码具有更好的解码效率和更好的容错性。 36 | 37 | 非线性码则没有这样的性质，因此其计算和解码难度较大。 38 | 39 | ### 4. 前向纠错码和反向纠错码 40 | 41 | 前向纠错码主要应用于低错误概率环境下的数字通信系统，如无线电通信、卫星通信等。常见的前向纠错码包括海明码、Reed-Solomon码、BCH码等。 42 | 43 | 反向纠错码主要应用于高错误概率环境下的数据存储和传输系统，如硬盘驱动器、内存芯片、光盘等。常见的反向纠错码包括LDPC码、Turbo码等。 44 | 45 | ## 三、纠删码的应用 46 | 47 | ### 1. 数字通信 48 | 49 | 纠删码在数字通信领域中得到广泛应用，它可以提高无线信道的质量和传输速率。例如，在GSM、CDMA、Wi-Fi和LTE等无线通信标准中，都采用了纠删码技术。这些无线系统需要检测并纠正通过无线信道传输时受损的数据包，以实现清晰的语音和高速的数据传输。 50 | 51 | ### 2. 存储系统 52 | 53 | 纠删码在存储系统中也有着广泛的应用。存储设备如硬盘驱动器、内存芯片、光盘、U盘等都使用纠删码技术来检测和纠正存储数据中的错误。 54 | 55 | 例如，在RAID（Redundant Array of Independent Disks）存储系统中，磁盘阵列通过在多个磁盘上存储冗余数据来提高可靠性和容错性。如果一个或多个磁盘出现错误或故障，纠删码可以帮助恢复原始数据。 56 | 57 | ### 3. 信息理论 58 | 59 | 纠删码是信息论中的重要概念。信息论是一种研究信息传输和处理的学科，旨在解决如何将信息在信道中传输的问题。纠删码通过增加冗余度来提高信息在传输过程中的可靠性，是信息理论中重要的一环。 60 | 61 | ### 4. 区块链 62 | 63 | 纠删码也被应用于区块链技术中。在区块链中，数据通过分布式存储方式进行存储和传输。由于可能存在攻击者对节点进行攻击或故障造成的数据损失，因此需要采取纠删码等方式来确保数据的完整性和可靠性。 64 | 65 | ​ 纠删码在区块链技术中的应用场景主要包括以下几个方面： 66 | 67 | ### 1. 数据完整性验证 68 | 69 | 区块链技术通过分布式存储方式来存储和传输数据，但在这个过程中可能会遇到由于节点攻击或故障等原因导致数据损失或篡改的问题。纠删码可以应用于数据完整性验证，通过添加冗余信息来检测并纠正因数据损失或篡改而引起的错误。 70 | 71 | 例如，区块链上存储的交易数据、智能合约代码等都可能涉及到敏感信息和重要数据，采用纠删码来确保数据的完整性是非常必要的。 72 | 73 | ### 2. 数据恢复 74 | 75 | 区块链技术中的数据存储和传输是去中心化的，多个节点共同维护着整个网络的数据。如果某些节点发生故障，就可能导致部分数据丢失。此时，纠删码可以帮助从其他节点的冗余备份中快速恢复数据。 76 | 77 | ### 3. 提高可靠性和容错性 78 | 79 | 区块链技术中的数据存储和传输往往会遇到高强度攻击和网络故障等问题。采用纠删码可以提高区块链系统的可靠性和容错性，从而增强了整个网络的稳定性。 80 | 81 | ### 4. 加密通信 82 | 83 | 纠删码还可以用于加密通信中。目前的一些区块链应用采用了分布式节点共识等机制来保证数据的安全，但在实际应用场景中，由于用户数量众多、设备类型不同等原因，可能会出现一些通信故障或丢失的情况。这时候，采用纠删码技术可以有效地增强加密通信的安全性，减少通信错误和数据丢失的概率。 84 | 85 | 总之，纠删码在区块链技术中有着广泛的应用前景，特别是在保障数据完整性、提高系统可靠性和容错性等方面，具有重要的作用。 86 | 87 | ## 四、总结 88 | 89 | 纠删码是一种通过添加冗余信息来检测和纠正数据错误的编码技术。它可以提高数字通信、存储系统和信息理论等领域中数据的可靠性和容错性。纠删码包括块编码和卷积码、线性码和非线性码、前向纠错码和反向纠错码等。 纠删码已在无线通信标准、存储设备、信息理论和区块链技术等众多领域得到广泛应用。 -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/zkroullup/zksync2.0.md: -------------------------------------------------------------------------------- 1 | ## 介绍 2 | 3 | Zksync 是 zkrollup, 使用加密有效性证明在以太坊上提供可扩展和低成本交易的无信任协议。 4 | 5 | ## zksync 概述 6 | 7 | Rollup 需要 operator 将交易汇总在一起，计算出正确状态状态的零知识证明，再和 roullup 合约交互来影响状态转换。 8 | 9 | zksync 的 rollup 操作如下： 10 | 11 | - 用户创建交易或者优先级操作 12 | - 处理此请求后，Operator 创建 rollup 操作并将其添加到L2块中 13 | - 一旦L2区块完成，运营商区块证明作为区块承诺提交给 zksync 合约，合约将会校验 rollup的部分逻辑，验证成功则看做最终状态 14 | 15 | L2 区块的生命周期 ： 16 | 17 | - Pending :operator 接收到交易 18 | - Processed ：交易被 operator 执行并确认包含在下个区块中 19 | - Committed ：表明该区块的交易数据已发布在以太坊上。它不能证明它是以有效的方式执行的，但它确保了块数据的可用性。 20 | - Finalized ：这表明交易的SNARK有效性证明已提交并由智能合约验证（一笔笔的交易由L1打包）。在这一步骤之后，交易被认为是最终的 21 | 22 | 从 Processed 到 Finalized 要经历几个小时。 23 | 24 | zksync2.0 支持的功能如下： 25 | 26 | - ECDSA签名的本机支持：任何帐户都可以在 L2 中使用与 L1 相同的私钥进行管理 27 | - 支持 solidity 0.8.x 28 | - Web3 API与以太坊完全兼容。这允许与现有的索引器、浏览器等无缝集成。 29 | - 支持 keccak256、 sha256 和 ecrecover通过预编译 30 | - hardhat 插件支持在 zksync 上简单测试和开发 31 | - 支持 从以太坊上传递数据到 zksync 上的合约 32 | 33 | 34 | 35 | ## 了解zksync 36 | 37 | ### 收费机制 38 | 39 | ### 跨链桥 40 | 41 | L1和L2各部署一个合约，来作为桥接。开发人员可以自由为任何代币建造自己的桥梁。但是，我们提供默认的桥梁（一个用于ETH，另一个用于ERC20代币），可用于基本桥接。 42 | 43 | #### 存钱到L2 44 | 45 | 用户调用 L1 bradge合约的 存款方法，将会触发以下事件： 46 | 47 | - 用户在L1 上的token会被发送到 L1 bridge 并被锁住 48 | - L1 bridge 合约会启动一笔交易发送到 L2 bridge 通过 L1->L2 (这是个什么) 49 | - 在L2交易中，token 将被 mint 并发送到L2上的指定地址 50 | - 如果zkSync上还不存在令牌，则会为其部署新的合约。假设L2令牌地址是确定性的（基于原始L1地址、名称和符号），不管谁是第一个桥接它的人，新的L2地址都是相同的。 51 | - 对于每个执行的L1->L2交易，都会有一条L2->L1日志消息确认其执行。 52 | 53 | warning： 54 | 55 | 如果此交易出于任何原因失败（例如，提供的费用太低），则日志消息将陈述其故障。在这种情况下，可以在L1桥上证明包含日志，以通过调用Moded sopairfailedDeposit将存入资金退还给原始发件人 56 | 57 | #### 提款到L1 58 | 59 | 用户调用取款操作在 L2 bradge 合约上，将会触发以下动作： 60 | 61 | - L2的token会被burn掉 62 | - 一个 L2->L1 的消息关于提款的 会被发送 63 | - 之后，撤回操作将可由L1 bradge 中的任何人最终完成（通过证明包含L2->L1消息，这是在调用L1 网桥中的的finlizeWithdraw方法时完成的） 64 | - 调用方法后，资金从L1 bradge 解锁并发送给提款接收者 65 | 66 | warning ： 67 | 68 | 在测试网环境上，我们会自动确定所有提款，即，对于每次提款，我们将通过进行L1交易来照顾它，以证明每条消息包含在内。 69 | 70 | ### L1/L2互操作性 71 | 72 | #### 优先级队列 73 | 74 | 75 | 76 | #### L2->L1 消息传递 77 | 78 | 与 L1 -> L2 通信相反，仅基于传输信息，而不是基于 L1 上的事务执行。它是一个内置功能，由两部分组成：从 L2 发送消息和在 L1 上读取消息。第一个是作为对 L2 系统智能合约的调用来实现的。第二个是在 zkSync L1 智能合约上作为 getter 函数实现的。 79 | 80 | 发送消息： 81 | 82 | 从 L2 发送到 L1 的每条消息都包含发送者的地址和消息本身。消息的长度可以任意大，但是消息越长，发送的成本就越高。操作员必须包括相应 merkle 根的所有消息（见下一段）。因此，所有消息都是公开可用的，不必依赖运营商来披露它们 83 | 84 | 阅读消息 85 | 86 | 发送的每条消息都可以在链上读取。此外，可以证明消息已在特定的 L2 块中发送。为了使这种证明对用户和运营商都尽可能便宜，我们将每个 L2 块的所有消息存储在 merkle 树中。因此，任何 L1 智能合约都可以通过提供包含在某个 L2 块中的证明来使用发送的消息。只能基于运营商发送给 zkSync L1 智能合约的数据生成证明。也可以通过[API](https://v2-docs.zksync.io/api/api.html#zksgetl2tol1msgproof)获得证明 87 | 88 | 总结： 89 | 90 | - L2 -> L1 通信需要 L2 上的一个事务和 L1 上的一个事务。 91 | - 消息可以是任意长度。 92 | - 证明消息包含在 L2 块中所需的所有数据始终可以从以太坊恢复。但是，最简单的方法是通过 API 向运营商请求证明。 93 | 94 | ## L1->L2 交流 95 | 96 | 交易有 base fee, 基于交易的ergslimit 和L1上的gas price 得出的，目前来说L1-> L2的交易都是先进先出方式。 97 | 98 | 99 | 100 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism spec分析/optimism介绍篇.md: -------------------------------------------------------------------------------- 1 | Optimism 是一个 EVM 等效的乐观汇总协议，旨在扩展以太坊，同时保持与现有以太坊基础设施的最大兼容性。本文档概述了协议，为规范的其余部分提供上下文。 2 | 3 | 4 | 5 | ## 功能 6 | 7 | ### 扩展性 8 | 9 | 扩展以太坊意味着增加以太坊网络可以处理的有用交易的数量。以太坊有限的资源，特别是带宽、计算和存储，限制了网络上可以处理的交易数量。在这三种资源中，计算和存储是目前最显着的瓶颈。这些瓶颈限制了交易的供应，导致极高的费用。可以通过更好地利用带宽、计算和存储来实现扩展以太坊和降低费用。 10 | 11 | ### 什么是乐观rollup 12 | 13 | Optimistic rollup 是一种第 2 层可扩展性技术，可在不牺牲安全性或分散性的情况下增加以太坊的计算和存储容量。交易数据在链上提交但在链下执行。如果链下执行出现错误，可以在链上提交错误证明来纠正错误，保护用户资金。同样，除非有争议，否则你不会上法庭，除非出现错误，否则你不会在链上执行交易。 14 | 15 | ### EVM 等效 16 | 17 | EVM Equivalence 完全符合以太坊黄皮书描述的状态转换函数，协议的正式定义。通过在 EVM 等效汇总中符合以太坊标准，智能合约开发人员可以编写一次并部署到任何地方。 18 | 19 | ## 网络参与者 20 | 21 | users, sequencers, and verifiers. 22 | 23 | ![网络参与者](https://github.com/ethereum-optimism/optimism/blob/65ec61dde94ffa93342728d324fecf474d228e1f/specs/assets/network-participants-overview.svg) 24 | 25 | ----- 26 | 27 | user： 28 | 29 | - 通过将数据发送到以太坊主网上的合约，在 L2 上存入或提取任意交易。 30 | - 通过将交易发送到sequencer，在第 2 层使用 EVM 智能合约。 31 | - 使用网络验证者提供的区块浏览器查看交易状态。 32 | 33 | Sequencer: 34 | 35 | Sequencer是主要的块生产者。可能有一个或多个使用共识协议的Sequencer。对于 1.0.0，只有一个排序器（目前在 Optimism Foundation 的监督下运行）。通常，规范可能会使用“定序器”作为由多个定序器操作的共识协议的替代术语。 36 | 37 | 1. 接受用户链下交易（L2） 38 | 2. 观察链上交易（主要是来自 L1 的存款事件） 39 | 3. 将**两种交易合并到具有特定顺序的 L2** 块中。 40 | 4. 通过将两个东西作为calldata提交给 L1，将合并的 L2 块传播到 L1： 41 | - 在步骤 1 中接受的pending链下交易。 42 | - 关于链上交易顺序的足够信息，以成功重建步骤 3 中的块，完全通过观察 L1 43 | 44 | Sequencer还提供早在步骤 3. 中访问块数据的权限，以便用户可以选择在 L1 确认之前访问实时状态。 45 | 46 | Verifiers: 47 | 48 | - 向用户提供rollup数据；和 49 | - 验证rollup完整性并争论无效断言。 50 | 51 | 为了让网络保持安全，必须**至少有一个诚实的验证者**能够验证rollup链的完整性并为用户提供区块链数据。 52 | 53 | ### 关键交互图 54 | 55 | 下图演示了在关键用户交互期间如何使用协议组件，以便在深入研究任何特定组件规范时提供上下文 56 | 57 | 存钱和发送交易： 58 | 59 | 用户通常会通过从 L1 存入 ETH 来开始他们的 L2 旅程。一旦他们有 ETH 来支付费用，他们就会开始在 L2 上发送交易。下图演示了这种交互以及所有已使用或应该使用的关键 Optimism 组件： 60 | 61 | 62 | 63 | 这个图中涉及到的组件链接 64 | 65 | - [Rollup Node](https://github.com/ethereum-optimism/optimism/blob/develop/specs/rollup-node.md) 66 | - [Execution Engine](https://github.com/ethereum-optimism/optimism/blob/develop/specs/exec-engine.md) 67 | 68 | - [L2 Output Oracle](https://github.com/ethereum-optimism/optimism/blob/develop/specs/proposals.md#l2-output-oracle-smart-contract) 69 | - [L2 Output Submitter](https://github.com/ethereum-optimism/optimism/blob/develop/specs/proposals.md#proposing-l2-output-commitments) 70 | 71 | 提款： 72 | 73 | 与存款一样重要的是，用户可以从rollup中退出是至关重要的。提款由 L2 上的正常交易发起，但在争议期结束后使用 L1 上的交易完成。 74 | 75 | 76 | 77 | 这个图中涉及到的组件链接 78 | 79 | - [L2 Output Oracle](https://github.com/ethereum-optimism/optimism/blob/develop/specs/proposals.md#l2-output-oracle-smart-contract) -------------------------------------------------------------------------------- /DApp_Development/合约基础/solidity_staticcall.md: -------------------------------------------------------------------------------- 1 | # Solidity `staticcall` 的用法和注意事项 2 | 3 | 在 Solidity 中，`staticcall` 是一种用于在智能合约中调用另一个智能合约的功能。与 `call` 和 `delegatecall` 不同，`staticcall` 不会修改状态或更改合约存储。`staticcall` **只会执行可视部分和纯函数并返回结果**。本文将详细介绍 `staticcall` 的用法，应用场景，注意点和安全性。 4 | 5 | ## 用法 6 | 7 | `staticcall` 函数定义如下： 8 | 9 | ```solidity 10 | function staticcall(address _target, bytes memory _data) public view returns (bool success, bytes memory returnData) 11 | ``` 12 | 13 | `staticcall` 函数的第一个参数指定要调用的合约地址，第二个参数是要调用的字节数组，也就是要调用的函数和参数。`staticcall` 函数的返回值是一个元组，第一个参数表示函数调用是否成功，第二个参数是返回的字节数组，包含调用函数的返回值。 14 | 15 | 下面是一个简单的示例，用于演示如何使用 `staticcall` 函数调用另一个合约中的函数，并获取其返回值。 16 | 17 | ```solidity 18 | pragma solidity ^0.8.0; 19 | 20 | contract Target { 21 | function getName() public view returns (string memory) { 22 | return "Target Contract"; 23 | } 24 | } 25 | 26 | contract Caller { 27 | function callGetName(address _target) public view returns (string memory) { 28 | (bool success, bytes memory returnData) = _target.staticcall( 29 | abi.encodeWithSignature("getName()") // 调用目标合约的 getName 函数 30 | ); 31 | require(success, "Staticcall to target contract failed"); 32 | return abi.decode(returnData, (string)); // 解码返回的字节数组 33 | } 34 | } 35 | ``` 36 | 37 | 在上述代码示例中，我们定义了两个合约，`Target` 和 `Caller`。在 `Target` 合约中，我们定义了一个 `getName` 函数，该函数返回 "Target Contract"。在 `Caller` 合约中，我们使用 `staticcall` 函数调用 `Target` 合约中的 `getName` 函数，并获得其返回值。 38 | 39 | 需要注意的是，`staticcall` 函数必须声明为 `view` 或 `pure`，以确保它不会修改任何状态。此外，由于 `staticcall` 只能调用合约中的视图和纯函数，并且不能调用修改状态的函数，因此在智能合约中使用 `staticcall` 通常只用于获取其他合约的状态或执行与状态无关的计算。 40 | 41 | ## 应用场景 42 | 43 | `staticcall` 函数可以用于以下场景： 44 | 45 | ### 调用其他合约的只读函数 46 | 47 | 在智能合约中，您可能需要查询其他合约的存储状态或执行其他合约中的只读函数，例如查询代币余额或查询外部服务的数据。在这种情况下，您可以使用 `staticcall` 函数来调用其他合约中的函数，而无需将其作为交易广播到区块链网络中。 48 | 49 | ### 将代码封装到固定地址 50 | 51 | 在某些情况下，您可能需要将可重用的代码封装到一个合约中，并将该合约的地址硬编码到您的合约中。在这种情况下，您可以使用 `staticcall` 函数来调用已存储在硬编码地址中的合约中的函数，而无需部署一个新的合约实例。 52 | 53 | ## 注意点和安全性 54 | 55 | 由于 `staticcall` 函数只能执行视图函数和纯函数，并且不能调用修改状态的函数，因此它比 `call` 和 `delegatecall` 更安全。但是，通过 `staticcall` 能够执行合约中的其中一些函数，在某些情况下可能会存在潜在的攻击风险。 56 | 57 | 以下是一些使用 `staticcall` 函数时应该注意的事项： 58 | 59 | ### 始终检查返回值 60 | 61 | 在使用 `staticcall` 函数时，请始终检查返回值，以确保函数调用成功并返回了预期的结果。如果返回值未被检查，则可能会受到攻击，例如重入攻击。 62 | 63 | ### 永远不要使用 `this` 访问实例变量 64 | 65 | 在 `staticcall` 函数中，您不能访问 `this` 引用，因为您不能修改状态。因此，您不能访问存储在合约中的状态变量。如果您需要访问该变量，请改为将合约地址作为参数传递，并从函数方法调用中返回状态值。 66 | 67 | ### 在使用 `staticcall` 函数时，应谨慎使用底层类型 68 | 69 | 在使用 `staticcall` 函数时，请避免使用底层类型。底层类型的使用可能会导致数据错误或安全漏洞，并可能使您的合约更难以维护。 70 | 71 | ### 在使用 `staticcall` 函数时，请确保您信任目标合约 72 | 73 | 使用 `staticcall` 函数调用另一个合约时，请确保您信任该合约，并仔细评估其中包含的代码。目标合约可能包含有意或无意的漏洞或恶意代码，这可能会使您的合约受到攻击。 74 | 75 | ### 防止重入攻击 76 | 77 | 重入攻击是指通过在相同的函数中重新调用一个合同来多次调用一个函数。要防止重入攻击，请确保您的合约在调用其他合约之前，已经执行过必要的检查，并始终在函数开头执行锁定操作。 78 | 79 | ## 结论 80 | 81 | `staticcall` 是 Solidity 中非常有用的功能之一，可以安全地在智能合约中调用其他合约中的视图和纯函数，而无需修改状态或更改合约存储。使用 `staticcall` 函数的主要用途是查询其他合约的状态或执行与状态无关的计算。在使用 `staticcall` 函数时，需要特别注意潜在的安全风险，并采取必要的措施来防范攻击。 -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/cosmos/ibc/cross chain via relayer.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## build ibc module 4 | 5 | Reference: https://docs.ignite.com/guide/ibc 6 | 7 | ```shell 8 | ignite chain serve --reset-once --config earth.yml 9 | ignite chain serve --reset-once --config mars.yml 10 | ``` 11 | 12 | ## change config.toml 13 | 14 | fix :error query block data 15 | 16 | The relayer looks back in time at historical transactions and needs to have an index of them. 17 | 18 | Specifically check `~/./config/config.toml` has the following fields set: 19 | 20 | ```toml 21 | indexer = "kv" 22 | index_all_tags = true 23 | ``` 24 | 25 | ## config relayer 26 | 27 | **[Configure the chains you want to relay between]** 28 | 29 | ```shell 30 | rly config init 31 | ``` 32 | 33 | **[Configure the chains you want to relay between]** 34 | 35 | ```shell 36 | rly chains add --file ibc-0.json ibc0 37 | rly chains add --file ibc-1.json ibc1 38 | ``` 39 | 40 | **[Import OR create new keys for the relayer to use when signing and relaying transactions.]** 41 | 42 | ```shell 43 | ## represent realyer memonic 44 | rly keys restore ibc0 relayer "equal party manual lottery glimpse guard giggle idle winner hundred pizza donkey maximum camera crystal camp bulb wine wild prosper digital oyster left monster" 45 | 46 | 47 | rly keys restore ibc1 relayer "prison combine panther someone crack pigeon junior remember uniform power cupboard humor such spin tuna urge oak amused crisp zone unknown lab easily mammal" 48 | ``` 49 | 50 | **[change config.yaml key as relayer]** 51 | 52 | ```shell 53 | global: 54 | api-listen-addr: :5183 55 | timeout: 10s 56 | memo: "" 57 | light-cache-size: 20 58 | chains: 59 | ibc0: 60 | type: cosmos 61 | value: 62 | key-directory: /Users/carver/.relayer/keys/earth 63 | key: "relayer" ## change 64 | 65 | ibc1: 66 | type: cosmos 67 | value: 68 | key-directory: /Users/carver/.relayer/keys/mars 69 | key: "relayer" ## change 70 | chain-id: mars 71 | ``` 72 | 73 | 74 | 75 | **[Ensure the keys associated with the configured chains are funded.]** 76 | 77 | ```shell 78 | rly q balance ibc0 79 | rly q balance ibc1 80 | ``` 81 | 82 | **[Create Path Across Chains.]** 83 | 84 | ```shell 85 | 1. Add basic path info to config 86 | rly paths new earth mars demo-path 87 | 88 | 2. Next we need to create a channel, client, and connection 89 | a. rly transact clients demo-path 90 | b. rly transact connection demo-path 91 | c. rly transact channel demo-path --src-port blog --dst-port blog --version blog-1 92 | ``` 93 | 94 | **[Finally, we start the relayer on the desired path]** 95 | 96 | ```shell 97 | rly paths list 98 | rly start [path] 99 | rly start 100 | ``` 101 | 102 | 103 | 104 | ## send IBC msg 105 | 106 | Reference: https://docs.ignite.com/guide/ibc 107 | 108 | 109 | 110 | 111 | 112 | -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/密码学中的数学/数论基础/数论_模运算.md: -------------------------------------------------------------------------------- 1 | # 模运算的定义和性质 2 | 3 | ## 模运算的定义 4 | 5 | 模运算又称同余运算，用符号"≡"表示，它指的是两个数对于某个数的余数具有相同的性质。具体来说，如果a和b是整数，n是正整数，那么我们称a和b在模n下同余，如果a和b对n取余后余数相同，即(a mod n) = (b mod n)。 6 | 7 | 形式化的表示为： 8 | a ≡ b (mod n) 9 | 10 | 上面的式子可以理解为：a和b是关于模数n的等价类，也可以表示为a = b + kn，其中k为整数。 11 | 12 | 例如，12≡5 (mod 7)，因为12和5在模7下的余数相同，都是5。 13 | 14 | ## 模运算的性质 15 | 16 | - 传递性：如果a≡b(mod n)，b≡c(mod n)，那么a≡c(mod n)。 17 | - 对称性：如果a≡b(mod n)，那么b≡a(mod n)。 18 | - 反身性：对于任何整数a和正整数n，a≡a(mod n)。 19 | - 同加法的分配律和结合律等类似。 20 | 21 | 模运算的这些性质很重要，可以使我们在解题和证明过程中简化运算和推导，提高工作效率。 22 | 23 | # 模运算的逆元 24 | 25 | 模运算的逆元指的是模n下的一个数b，与a模n之后的余数乘积等于1，即(a * b) ≡ 1 (mod n)。那么我们就称b为a的模n逆元。如果不存在a的逆元，那么a就没有模n下的乘法逆元。 26 | 27 | 我们可以看一个例子来理解模运算的逆元： 28 | 29 | 假设n=7，我们要求5在模7下的逆元b，也就是找到一个整数b，使得5*b ≡ 1 (mod 7)。 30 | 31 | 根据模运算的定义，我们可以得到：5*b ≡ 1 (mod 7) 等价于 5b = 7k + 1。 32 | 33 | 我们现在来尝试找到这样的b值。我们可以用暴力枚举的方法，从0开始尝试每个整数，如果找到了一个数，满足上面的等式，那么它就是5在模7下的逆元。根据上面的式子，我们可以列出下面的表格： 34 | 35 | | b | 5\*b | 7\*k | 7\*k+1 | 36 | | ---- | ---- | ---- | ------ | 37 | | 0 | 0 | 0 | 1 | 38 | | 1 | 5 | 0 | 7 | 39 | | 2 | 10 | 7 | 15 | 40 | | 3 | 15 | 14 | 22 | 41 | | 4 | 20 | 21 | 29 | 42 | | 5 | 25 | 28 | 36 | 43 | 44 | 从表中可以看出，当b=3时，满足等式5b = 7k + 1。也就是说，5在模7下的逆元为3。因为5\*3=15=2\*7+1，5和3的乘积模7之后余数为1，满足逆元定义。 45 | 46 | 如果我们不使用暴力枚举的方法，而是使用扩展欧几里得算法，则可以更加高效地求出模的逆元。 47 | 48 | # 模运算的应用 49 | 50 | ## 密码学中的应用 51 | 52 | 模运算在密码学中的应用非常广泛。下面以RSA加密算法为例，简单地介绍一下模运算在密码学中的应用。 53 | 54 | RSA加密算法是一种基于公钥密码学的加密算法，其核心原理是基于质因数分解难题，使用大素数和模运算实现加密和解密。 55 | 56 | 在RSA算法中，我们需要选择两个大的质数p和q，然后计算n=pq，再根据欧拉函数计算φ(n)=(p-1)(q-1)，然后从φ(n)的值中选择一个与之互质的整数e，作为加密密钥。最后，我们根据e和φ(n)的值，使用模运算计算d，作为解密密钥。 57 | 58 | 具体来说，如果我们已知e和φ(n)的值，我们可以使用扩展欧几里得算法求得e在模φ(n)下的逆元d，即d * e ≡ 1 (mod φ(n))。RSA中，e称为加密指数，n称为模数，d称为解密指数。当我们需要进行加密时，我们将明文m进行加密，得到密文c，其计算公式为： 59 | 60 | c ≡ m^e (mod n) 61 | 62 | 当我们需要进行解密时，我们将密文c进行解密，得到明文m，其计算公式为： 63 | 64 | m ≡ c^d (mod n) 65 | 66 | 可以看出，RSA算法中的加密和解密过程都是基于模运算实现的。因为计算n、φ(n)和d的过程都基于大素数的运算，故而RSA算法是一种非常安全的加密算法，至今仍被广泛应用于信息安全领域。 67 | 68 | ## 计算机科学中的应用 69 | 70 | 在计算机科学中，模运算也被广泛应用，如校验码算法、哈希算法、错误校正码等等，都是基于模运算实现的。 71 | 72 | 下面以校验码算法为例，简单地介绍一下模运算在计算机科学中的应用。 73 | 74 | 校验码算法是一种在数据传输过程中，检查数据是否出现错误的方法。我们在计算机中传输数据时，往往需要进行错误校验和纠正。而校验码算法就是用来检验和纠正错误的。 75 | 76 | 在校验码算法中，我们经常使用模10的校验码。模10校验码的计算方法就是将每个数字加权相加后，取其个位数，就是模10的校验码。例如，对于一个包含7位数字的数据串"1234567"，我们可以通过下面的计算方法，计算出其校验码： 77 | 78 | 1. 把数字从右侧开始标号为1、2、3……，直到最左边的数字，得到编号n； 79 | 2. 对于每个数字，将其与数字的位置对应，乘以对应的权值，将它们相加； 80 | 3. 取该加权后的总和的个位数，得到模10校验码。 81 | 82 | 具体来说，对于字符串"1234567"，我们可以将其从右至左进行编号，得到下面的表格： 83 | 84 | | 数字 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 85 | | ----------- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | 86 | | 编号 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 87 | | 权值 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 88 | | 数字 * 权值 | 14 | 12 | 10 | 8 | 6 | 4 | 2 | 89 | 90 | 然后，将乘积相加，得到56，最后再取个位数6，即为模10的校验码。 91 | 92 | 由于模10校验码的计算过程中，涉及到模运算等重要数学概念，因此计算机科学中的许多算法和技术都会涉及到模运算的应用。 93 | 94 | # 总结 95 | 96 | 模运算是一种非常重要的数学运算，它能够广泛应用于密码学、计算机科学、物理学等领域 97 | 98 | -------------------------------------------------------------------------------- /Layer2_Solutions/layer2/optimism/optimism spec分析/op-系统配置.md: -------------------------------------------------------------------------------- 1 | # 系统配置 2 | 3 | **目录** 4 | 5 | - 系统配置内容（版本0） 6 | - [`batcherHash`( `bytes32`)](https://github.com/ethereum-optimism/optimism/blob/develop/specs/system_config.md#batcherhash-bytes32) 7 | - [`overhead`和`scalar`( `uint256,uint256`)](https://github.com/ethereum-optimism/optimism/blob/develop/specs/system_config.md#overhead-and-scalar-uint256uint256) 8 | - [`gasLimit`( `uint64`)](https://github.com/ethereum-optimism/optimism/blob/develop/specs/system_config.md#gaslimit-uint64) 9 | - [`unsafeBlockSigner`( `address`)](https://github.com/ethereum-optimism/optimism/blob/develop/specs/system_config.md#unsafeblocksigner-address) 10 | - [编写系统配置](https://github.com/ethereum-optimism/optimism/blob/develop/specs/system_config.md#writing-the-system-config) 11 | - [读取系统配置](https://github.com/ethereum-optimism/optimism/blob/develop/specs/system_config.md#reading-the-system-config) 12 | 13 | 这`SystemConfig`是 L1 上的合约，可以将汇总配置更改作为日志事件发出。汇总块[派生过程](https://github.com/ethereum-optimism/optimism/blob/develop/specs/derivation.md)会获取这些日志事件并应用更改。 14 | 15 | ## 系统配置内容（版本0） 16 | 17 | 系统配置合约版本0定义了以下参数： 18 | 19 | ### `batcherHash`( `bytes32`) 20 | 21 | 当前授权批处理发送者的版本化哈希，用于作为批处理提交者轮换密钥。第一个字节标识版本。 22 | 23 | 版本`0`将当前批次提交者以太坊地址 ( `bytes20`) 嵌入版本化哈希的最后 20 个字节中。 24 | 25 | 将来，此版本化哈希可能会成为对更广泛配置的承诺，以实现更广泛的冗余和/或轮换配置。 26 | 27 | ### `overhead`和`scalar`( `uint256,uint256`) 28 | 29 | L1 费用参数，也称为 Gas Price Oracle (GPO) 参数，会同时更新，并将新的 L1 成本应用于 L2 交易。 30 | 31 | ### `gasLimit`( `uint64`) 32 | 33 | L2 块的 Gas 限制通过系统配置进行配置。L2 气体限制的更改完全应用于引入更改的 L1 源的第一个 L2 块，而不是像 L1 块的限制更新中所示的针对目标的 1/1024 调整。 34 | 35 | ### `unsafeBlockSigner`( `address`) 36 | 37 | 区块在 L1 上可用之前，会在 p2p 网络中传播。为了防止 p2p 层上的拒绝服务，这些不安全块必须使用特定密钥进行签名，才能被接受为“规范”不安全块。该键对应的地址是`unsafeBlockSigner`. 为了确保它的值可以通过存储证明以独立于存储布局的方式获取，它被存储在对应于 的特殊存储槽中 `keccak256("systemconfig.unsafeblocksigner")`。 38 | 39 | 与其他值不同，`unsafeBlockSigner`唯一的值根据区块链策略运行。它不是共识级别参数。 40 | 41 | ## 编写系统配置 42 | 43 | 合约`SystemConfig`对所有写入合约功能进行认证，配置管理可以配置为任何类型的以太坊账户或合约。 44 | 45 | 写入时，会发出一个事件，以便 L2 系统拾取更改，并且新写入的配置变量的副本保留在 L1 状态中，以便通过 L1 合约进行读取。 46 | 47 | ## 读取系统配置 48 | 49 | Rollup 节点通过根据其过去的 L2 链查找起点来初始化其派生过程： 50 | 51 | - 当从 L2 创世开始时，将从汇总链配置中检索初始系统配置。 52 | - 当从现有的 L2 链启动时，先前包含的 L1 块被确定为派生起点，因此可以从引用 L1 块作为 L1 起源的最后一个 L2 块中检索系统配置： 53 | - `batcherHash`，`overhead`并`scalar`从 L1 区块信息交易中检索。 54 | - `gasLimit`从 L2 块头中检索。 55 | - 还可以从 L2 块的其他内容（例如标头）检索其他未来变量。 56 | 57 | 在为给定的 L1 起始输入准备好初始系统配置后，系统配置将通过处理来自每个新 L1 块的所有接收来更新。 58 | 59 | 对包含的日志事件进行过滤和处理，如下所示： 60 | 61 | - 日志事件合约地址必须与汇总`SystemConfig`部署匹配 62 | 63 | - 第一个日志事件主题必须与 ABI 哈希匹配`ConfigUpdate(uint256,uint8,bytes)` 64 | 65 | - 第二个主题决定版本。未知版本是严重的推导错误。 66 | 67 | - 第三个主题确定更新的类型。未知类型是严重的推导错误。 68 | 69 | - 剩余的事件数据是不透明的，编码为ABI字节（即包括偏移量和长度数据），并对配置更新进行编码。版本中 70 | 71 | ``` 72 | 0 73 | ``` 74 | 75 | 支持以下类型： 76 | 77 | - type `0`：`batcherHash`覆盖，作为`bytes32`有效负载。 78 | - 输入`1`:`overhead`并`scalar`覆盖，作为两个打包`uint256`条目。 79 | - type `2`：`gasLimit`覆盖，作为`uint64`有效负载。 80 | - type `3`：`unsafeBlockSigner`覆盖，作为`address`有效负载。 81 | 82 | 请注意，各个推导阶段可能正在处理不同的 L1 块，因此应维护各个系统配置副本，并在该阶段遍历到下一个 L1 块时应用基于事件的更改。 -------------------------------------------------------------------------------- /Layer2_Solutions/b2network/committer.md: -------------------------------------------------------------------------------- 1 | ## 运行原理 2 | 3 | > https://github.com/b2network/b2-node/issues/93 4 | 5 | ![image-20240430102213666](https://p.ipic.vip/oorhic.png) 6 | 7 | 8 | 9 | 大致的步骤如下： 10 | 11 | 1. Aggregator 调用 polygonZkevm.sol 的verifyBatchesTrustedAggregator函数（🚩需要确认事件会提供什么数据） 12 | 13 | 2. B2-committer 监听上述事件保存到MySQL中 14 | 15 | 3. B2-commit 提交一个proposal 到b2-node （发送交易） 16 | 17 | 交易格式如下： 18 | 19 | ```go 20 | transaction { 21 | "proposalId": getLastProposalId() from b2-node api, 22 | "stateRoot": rootHash from a merkle tree which contains all the stateRoots of the batch, which are range of startBatchNum and endBatchNum 23 | "startBatchNum": getFinalBatch() from b2-node rpc or rest interface, 24 | "endBatchNum": startBatchNum + 10 (defined a constant) 25 | ``` 26 | 27 | 实际真正的proposal 生成依赖上面的交易数据： 28 | 29 | ```go 30 | proposal { 31 | "transaction": transaction from above describe, 32 | "currentBlockNum": the current b2-node block number, 33 | "voteMax": how many b2-committer node need to vote, 34 | "txVoteNum": voteNums Step3, 35 | "resultVoteNum": voteNums Step8, 36 | "winAddress": which address has the entitlement to execute submitter to submit data(stateRoot and proof) to btc network 37 | "btcTxId": btc tx id which contains the stateRoot and proof (🚩这个是指什么) 38 | "voteAdressList": already vote address list, 39 | "state": (PENDING, SUCCESS, TIMEOUT), 40 | } 41 | ``` 42 | 43 | 生成完proposal之后就记录这个proposalID 44 | 45 | 4. 从channel[proposalId]]中获取proposalId，并从b2节点api中搜索proposal状态。如果state为PENDING，则检查winAddress是否等于本地b2-committer地址，然后执行submitter向btc网络提交数据（stateRoot和proof） (相当于验证完2层交易后，2次最终性确认之后，再由一个共识网络进行小范围共识，最终提交到btc网络) 46 | 47 | 5. 从Step4中获取btcTxId，并将其放入通道[btcTxId]中，然后更新b2节点中的finalBatchNum （🚩这里的btcTxId是从第三步就已经出现了，是不是在那一步就已经提交到btc网络了？？） 48 | 49 | 6. 进入业务循环通道[btcTxId]，得到btcTxId，通过btcTxId查询btc网络的blockNum。如果已确认blockNum（大于7个块），则执行步骤7， （🚩这里的btcTxid 是否指的上面的） 50 | 51 | 7. the b2-committer which execute btc transaction and get the btcTxId update the proposal btcTxId. （🚩？） 52 | 53 | 8. 每个b2提交器节点循环它们的信道[proposealId]以检查btcTxId是否为空。如果不是，则检查btcTxId blockHeight并将事务提交给b2节点进行投票。resultVoteNum++。如果resultVoteNum>50%，则将状态更新为SUCCESS。 54 | 55 | 9. 通过通道[proposalId]中的proposalId循环检查proposal。如果proposal的状态仍然是PENDING并且（currentBlockNum-proposal.currentBlockNum）>10000，则将状态更新为TIMEOUT并再次执行步骤3。 56 | 57 | 58 | 59 | 60 | 61 | ## 大致代码设计 62 | 63 | - 开启了go 循环专门获取b2 zknode 的最新高度 和btc 最新高度， 将zknode 的区块同步到数据库 64 | - 从同步到数据库的zkevm 区块，去过滤Polygonzkevm 合约的verifyBatch log，按照区块，把log全部转成事件存储到数据库 65 | - 从数据库中查找proposal 相关记录根据lastFinalBatchNum(已经2次最终性确认，被验证过了)，最终是为了拿到VerifyRangBatchInfo（🚩，这部分代码涉及到zkevm 的设计原理），这个和proposalID进行挂钩，然后将stateroot 和proof (来源于VerifyRangBatchInfo)提交到B2-node (这是DA层). （配置的那个地址实际是b2-node上面的一个用户地址），如果没有问题，这个proposal相关的信息也会记录到数据库，**这个时候投票状态还没有记录。**，然后会有校验状态的进程去从b2node 查询，并更新到数据库。 66 | - 当从b2node里检查 那个proposal的BitcoinTxHash 如果没有的话，说明还没有刻到比特币中，（这里有两个地址，一个是committer在BTC的地址，还有一个是 目标地址《是否是需要刻入的的地址》） 67 | - 提交到taproot后，返回的bitcoinTxHash，将会写入到DA层，并和之前的proposalID 关联起来，然后同时也把这个proposal的某些字段更新到数据库（但是他后面又是在6个块确认后提交到DA，我不是很明白） -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊基础理论部分/钱包系列/详解私钥、密码、keystore和助记词.md: -------------------------------------------------------------------------------- 1 | > 文章以及资料（开源）：[github地址](https://github.com/mindcarver/blockchain_guide) 2 | 3 | [TOC] 4 | 5 | 6 | ## 密码 7 | 8 | 首先明白密码不是私钥，它是在创建账户时候的密码（**注意可以修改**）。密码在以下情况下会使用到： 9 | 10 | 1. 作为转账的支付密码 11 | 2. 用keystore导入钱包的时候需要输入的密码，用来解锁keystore的 12 | 13 | ## 私钥 14 | 15 | 私钥由64位长度的十六进制的字符组成，比如：`0xA4356E49C88C8B7AB370AF7D5C0C54F0261AAA006F6BDE09CD4745CF54E0115A`，**一个账户只有一个私钥且不能修改**，。通常一个钱包中私钥和公钥是成对出现的，有了私钥，我们就可以通过一定的算法生成公钥，再通过公钥经过一定的算法生成地址，这一过程都是不可逆的。私钥一定要妥善保管，若被泄漏别人可以通过私钥解锁账号转出你的该账号的数字货币。 16 | 17 | ## keystore 18 | 19 | Keystore常见于以太坊钱包，它是将私钥以加密的方式保存为一份 JSON 文件，这份 JSON 文件就是 keystore，所以它就是加密后的私钥。Keystore必须配合钱包密码才能使用该账号。 20 | 21 | Keystore 文件大致样子： 22 | 23 | ``` 24 | { 25 | "crypto" : { 26 | "cipher" : "aes-128-ctr", 27 | "cipherparams" : { 28 | "iv" : "83dbcc02d8ccb40e466191a123791e0e" 29 | }, 30 | "ciphertext" : "d172bf743a674da9cdad04534d56926ef8358534d458fffccd4e6ad2fbde479c", 31 | "kdf" : "scrypt", 32 | "kdfparams" : { 33 | "dklen" : 32, 34 | "n" : 262144, 35 | "r" : 1, 36 | "p" : 8, 37 | "salt" : "ab0c7876052600dd703518d6fc3fe8984592145b591fc8fb5c6d43190334ba19" 38 | }, 39 | "mac" : "2103ac29920d71da29f15d75b4a16dbe95cfd7ff8faea1056c33131d846e3097" 40 | }, 41 | "id" : "3198bc9c-6672-5ab3-d995-4942343ae5b6", 42 | "version" : 3 43 | } 44 | ``` 45 | 46 | 名词解释： 47 | 48 | - cipher：对称 AES 算法的名称; 49 | - cipherparams：上述 cipher 算法需要的参数; 50 | - ciphertext：你的以太坊私钥使用上述 cipher 算法进行加密; 51 | - kdf：密钥生成函数，用于让你用密码加密 keystore 文件; 52 | - kdfparams：上述 kdf 算法需要的参数; 53 | - Mac：用于验证密码的代码。 54 | 55 | ## 助记词 56 | 57 | 私钥是64位长度的十六进制的字符，不利于记录且容易记错，所以用算法将一串随机数转化为了一串12 ~ 24个容易记住的单词，方便保存记录。注意： 58 | 59 | 1. 助记词是私钥的另一种表现形式 60 | 2. 助记词可以获取相关联的多个私钥，反过来私钥没法获取助记词。 61 | 62 | 要弄清楚助记词与私钥的关系，得清楚BIP协议，是`Bitcoin Improvement Proposals`的缩写，意思是Bitcoin 的改进建议，用于提出 Bitcoin 的新功能或改进措施。BIP协议衍生了很多的版本，主要有BIP32、BIP39、BIP44。 63 | 64 | ### 以太坊对BIP的支持 65 | 66 | BIP是用于提出 Bitcoin 的新功能或改进措施，那么对于以太坊来说如何支持呢？ 67 | 68 | - 以太坊在[EIPs/issues/84](https://github.com/ethereum/EIPs/issues/84)中讨论，是否遵循 BIP32 和 BIP44，社区里提出来很多有意思的观点，比特币是基于 UTXO 的，所以可以使用 HD 钱包（BIP32）为每个交易分配一个新地址，以保护您的隐私。然而，以太坊是基于帐户，每个帐户都有一个地址，BIP 是比特币的提案，而且比特币的数据结构的设计是围绕改变地址的想法构建的，BIP 的一些提案可能并不适合以太坊。以太坊的模式和比特币UTXO 不同，以太坊转账不能改变地址，如果在以太坊上实现 UTXO ，用户还必须签名两个交易以将余额的一部分发送到一个地址，将余额的一部分发送到第二个地址 - 这将使成本增加一倍，而且第二个交易可能不会在同一个区块中，当然以太坊也可以通过智能合约的方式实现。另外，以太坊目前官方钱包采用 KDF 的形式，也就是我们常说的 Keystore 的形式。 69 | - 以太坊在[EIPs/issues/85](https://github.com/ethereum/EIPs/issues/85)中讨论，以太坊社区似乎也采用了 BIP32 的做法，提议 HD 路径为 : `m/44'/60'/0'/0/n`，n 是第 n 次生成地址。目前以太坊客户端实现了BIP32的客户端有：`Jaxx, Metamask, Exodus, imToken, TREZOR (ETH) & Digital Bitbox`。 70 | 71 | ## 密码、私钥、keystore与助记词的关系 72 | 73 | ![image-20201012091537816](https://tva1.sinaimg.cn/large/007S8ZIlgy1gjma8otsfxj314s0s0jvw.jpg) 74 | 75 | ## 如何解锁账户 76 | 77 | 解锁账户有如下几种方式： 78 | 79 | - 私钥（Private Key） 80 | - Keystore+密码（Keystore+Password） 81 | - 助记词（Mnemonic code） 82 | 83 | 我们可以得到以下总结： 84 | 85 | - 通过私钥+密码可以生成keystore，即加密私钥。 86 | - 通过keystore+密码可以获取私钥，即解密keystore。 87 | - 通过助记词根据不同的路径获取不同的私钥，即使用HD钱包将助记词转化成种子来生成主私钥，然后派生海量的子私钥和地址。 -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/以太坊基础理论部分/以太坊介绍.md: -------------------------------------------------------------------------------- 1 | > 文章以及资料（开源）：[github地址](https://github.com/mindcarver/blockchain_guide) 2 | 3 | [TOC] 4 | 5 | ## 定义 6 | 7 | 以太坊（英语：Ethereum）是一个开源的有智能合约功能的公共区块链平台。通过其专用加密货币以太币（Ether，又称“以太币”）提供去中心化的虚拟机（称为“以太虚拟机”Ethereum Virtual Machine）来处理点对点合约。 8 | 9 | ## 特点 10 | 11 | 相较于较大多数其他加密货币或区块链技术，以太坊的特点包括下列： 12 | 13 | - 智能合约（smart contract）：存储在区块链上的程序，由各节点运行，需要运行程序的人支付手续费给节点的矿工或权益人。 14 | - 分布式应用程序：以太坊上的分布式应用程序不会停机，也不能被关掉。 15 | - 代币（tokens）：智能合约可以创造代币供分布式应用程序使用。分布式应用程序的代币化让用户、投资者以及管理者的利益一致。代币也可以用来进行首次代币发行。 16 | - 叔块（uncle block）：将因为速度较慢而未及时被收入母链的较短区块链并入，以提升交易量。使用的是有向无环图的相关技术。 17 | - 权益证明（proof-of-stake）：相较于工作量证明更有效率，可节省大量在挖矿时浪费的电脑资源，并避免特殊应用集成电路造成网络中心化。（测试中） 18 | 19 | ## 第二层功能 20 | 21 | 除了在主链上运行的各种功能，为了支持智能合约所需的高运算量以及资料容量，以太坊也积极开发第二层功能来减轻主链的负担，扩展其实用规模。目前的主要方案包括以下： 22 | 23 | - 支链：用较小的分支区块链运算，只将最后结果写入主链，可提升供单位时间的工作量。 24 | - Plasma支链：2020年6月起由OMG测试中 25 | - Rollup支链：2019年开发团队将重心由Plasma转移至Rollup，目前正在开发中 26 | - 状态通道（state channels）：原理类似比特币的闪雷网络，可提升交易速度、降低区块链的负担，并提高可扩展性。尚未实现，开发团队包括雷电网络（Raiden Network）和移动性网络（Liquidity Network） 27 | - 分片（sharding）：减少每个节点所需纪录的资料量，并透过平行运算提升效率（尚未实现） 28 | 29 | ## 以太币 30 | 31 | 以太坊区块链上的代币称为以太币（Ether），代码为ETH，可在许多加密货币的外汇市场上交易，它也是以太坊上用来支付交易手续费和运算服务的介质。以太币的总发行量不明，因为权益证明的具体运作方式仍在研究中，而虽然难度炸弹限制了工作量证明的挖扩的区块数量上限，但因为叔块也有奖励，而且叔块的数量并不一定，造成确切数量难以估算。 32 | 33 | 以太币对其他实体货币的汇率可能在短时间内大幅变化，例如2016年 The DAO 被骇时，对美元的汇率从 $21.50 跌至 $15，而2017年初到2018年初的的一年间从大约10美金涨到1400美元。 34 | 35 | 布特林在 2016 年 4 月售出手上持有的四分之一以太币，造成一些人质疑，而他本人则说这是理财上很合理的分散风险，并引用前比特币开发员 Gavin Andresen 说这一切都还只是一场实验，仍有失败的可能。 36 | 37 | ## 智能合约 38 | 39 | 以太坊最重要的技术贡献就是智能合约。智能合约是存储在区块链上的程序，可以协助和验证合约的谈判和运行。以太坊的智能合约可以数种用图灵完备的编程语言写成。纽约时报称以太坊平台是一台由众多用户构成的网络来运转的公用电脑，并用以太币来分配和支付这台电脑的使用权。经济学人则说明智能合约可以让众多组织的数据库得以用低廉的成本交互，并且让用户写下精密的合约，功能之一是产生去中心化自治组织，也就是一间只是由以太坊合约构成的虚拟公司。 40 | 41 | 因为合约内容公开，合约可以证明其宣称的功能是真实的，例如虚拟赌场可以证明它是公平的。另一方面，合约的公开性也表示如果合约中有漏洞，任何人都可以立刻看到，而修正程序可能会需要一些时间。The DAO 就是一个例子，无法即时阻止。 42 | 43 | 智能合约的许多细节仍在研究中，包括如何验证合约的功能。微软研究院的报告指出要写出完善的合约可能非常困难，讨论了微软开发的一些可以用来验证合约的工具，并提到如果大规模分析各个已发布的合约，可能发现找出大量的漏洞。报告也说可以证明Solidity程序和以太虚拟机编码的等同性。 44 | 45 | ## 以太坊组件 46 | 47 | ### p2p网络 48 | 49 | 以太坊运行在Ethereum Main Network上，这是一个通过TCP 30303端口寻址的网络，网络层运行的协议名为-D ΞVp2p 50 | 51 | ### 共识规则 52 | 53 | 以太坊的共识规则，由以太坊黄皮书（见后文中的“扩展阅读”）中的参考标准进行精确定义 54 | 55 | ### 交易 56 | 57 | 以太坊交易是一个网络消息，主要包含交易的发送方、接收方、价值和数据载荷 58 | 59 | ### 状态机 60 | 61 | 以太坊的状态转换由以太坊虚拟机（EVM）处理，这是一个基于栈的虚拟机，执行bytecode（字节码指令）。被称为“智能合约”的EVM程序采用高级语言（例如Solidity）编写，并编译为通过EVM执行的字节码。 62 | 63 | ### 数据结构 64 | 65 | 以太坊的区块链以数据库（通常采用Google的LevelDB）的方式保存在每一个节点之上，区块链内包含了交易和系统的状态，经过哈希处理的数据保存在Merkle Patricia Tree数据结构之内。 66 | 67 | ### 经济安全性 68 | 69 | 以太坊当前使用名为Ethash的工作量证明算法，这个算法迟早将被放弃，并切换到PoS。 70 | 71 | ## 扩展阅读 72 | 73 | > 以太坊黄皮书：https://ethereum.github.io/yellowpaper/paper.pdf 74 | > 75 | > 黄皮书的简单版本：https://github.com/chronaeon/beigepaper 76 | > 77 | > DΞVp2p网络协议：https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol 78 | > 79 | > 以太坊虚拟机相关资源：https://github.com/ethereum/wiki/wiki/Ethereum-Virtual-Machine-(EVM)-Awesome-List 80 | > 81 | > MPT规范：https://github.com/ethereum/wiki/wiki/Patricia-Tree 82 | > 83 | > casper第一版协议：https://github.com/ethereum/research/wiki/Casper-Version-1-Implementation-Guide 84 | > 85 | > 《深入理解以太坊》 86 | 87 | -------------------------------------------------------------------------------- /DApp_Development/应用场景/智能合约可能的业务方向.md: -------------------------------------------------------------------------------- 1 | 智能合约是一种自动执行的计算机程序，它被编写在区块链上，可以帮助人们在没有中间人干扰的情况下进行透明、安全和可靠的交易。随着区块链技术的发展，智能合约在互联网行业中的应用场景越来越广泛。本文将详细描述智能合约在互联网行业中的各种场景。 2 | 3 | 一、电子商务场景 4 | 5 | 1、在线支付 6 | 7 | 智能合约可以被用来处理在线支付，使得买卖双方能够在没有中间人的情况下安全、快速地完成交易。例如，当用户在某个电商平台上购买商品时，智能合约可以自动将付款从买家的钱包中转移到卖家的钱包中，同时验证交易是否符合双方的要求。 8 | 9 | 2、供应链管理 10 | 11 | 智能合约可以被用来管理供应链，使得全球各地的供应商和客户能够实现无缝的沟通和协作。例如，当某个物流公司需要从一家供应商处采购原材料时，智能合约可以自动协调采购、运输和支付等环节，从而实现供应链的自动化管理。 12 | 13 | 3、数字版权保护 14 | 15 | 智能合约可以被用来保护数字版权，使得创作者能够更好地保护自己的作品不被盗版或侵权。例如，当某个创作者发布了一部电影或音乐作品时，智能合约可以自动记录版权信息，从而防止他人未经许可地使用这些作品。 16 | 17 | 二、金融服务场景 18 | 19 | 1、数字货币交易 20 | 21 | 智能合约可以被用来处理数字货币交易，使得交易更加安全、快速和透明。例如，当用户需要在加密货币交易平台上购买某个数字资产时，智能合约可以自动处理交易，从而确保交易的合法性和安全性。 22 | 23 | 2、借贷和投资 24 | 25 | 智能合约可以被用来管理借贷和投资，使得借贷和投资过程更加透明、自动化和安全。例如，当某个用户需要借款时，智能合约可以自动处理借款和还款等环节，从而减少人为干预和错误。 26 | 27 | 3、保险理赔 28 | 29 | 智能合约可以被用来管理保险理赔，使得理赔过程更加公正、快速和自动化。例如，当某个用户需要进行理赔时，智能合约可以自动处理理赔申请、审核和赔付等环节，从而提高用户体验和保险公司的效率。 30 | 31 | 三、医疗健康场景 32 | 33 | 1、健康数据管理 34 | 35 | 智能合约可以被用来管理个人健康数据，使得个人健康数据更加安全、私密和透明。例如，当某个患者需要将自己的健康数据存储在区块链上时，智能合约可以自动处理数据存储和访问权限等环节，从而保护患者的隐私和权益。 36 | 37 | 2、医疗资源调配 38 | 39 | 智能合约可以被用来管理医疗资源的调配，使得医疗资源的分配更加公平、高效和自动化。例如，当某个医院需要调配医疗资源时，智能合约可以自动处理资源调配和交易等环节，从而提高医疗资源的利用率和医疗服务的质量。 40 | 41 | 3、药品追溯管理 42 | 43 | 智能合约可以被用来管理药品的追溯和溯源，使得药品的来源和流通更加透明、可信和安全。例如，在药品的生产、运输和销售环节中，智能合约可以自动记录药品的信息和流向，从而保证药品的质量和安全。 44 | 45 | 四、物联网场景 46 | 47 | 1、智能家居管理 48 | 49 | 智能合约可以被用来管理智能家居设备，使得设备的控制更加智能、自动化和安全。例如，当用户需要控制智能家居设备时，智能合约可以自动处理设备的控制和数据传输等环节，从而提高用户的生活体验。 50 | 51 | 2、智能物流管理 52 | 53 | 智能合约可以被用来管理智能物流设备，使得物流的运输和交付更加智能、自动化和高效。例如，在物流的运输和交付环节中，智能合约可以自动处理运输和交付的序列、时间和地点等信息，从而实现物流的智能管理和优化。 54 | 55 | 3、智能能源管理 56 | 57 | 智能合约可以被用来管理智能能源设备，使得能源的生产和消费更加智能、自动化和节能。例如，在能源的生产和消费环节中，智能合约可以自动处理能源的生产、储存和消费等信息，从而实现能源的智能管理和优化。 58 | 59 | 五、社交媒体场景 60 | 61 | 1、数字身份管理 62 | 63 | 智能合约可以被用来管理数字身份，使得用户的身份和数据更加安全、私密和可信。例如，在社交媒体平台上，智能合约可以自动记录用户的身份和关注信息，从而保护用户的隐私和权益。 64 | 65 | 2、数字内容分发 66 | 67 | 智能合约可以被用来管理数字内容分发，使得数字内容的分发更加公正、高效和自动化。例如，在社交媒体平台上，智能合约可以自动处理数字内容的分发和版权管理等环节，从而保护内容创作者的利益和用户的体验。 68 | 69 | 3、社交网络治理 70 | 71 | 智能合约可以被用来管理社交网络的治理，使得社交网络的管理更加公正、透明和自动化。例如，在社交媒体平台上，智能合约可以自动处理用户的投诉、举报和封禁等事件，从而提高社交网络的公正性和管理效率。 72 | 73 | 六、游戏娱乐场景 74 | 75 | 1、游戏资产管理 76 | 77 | 智能合约可以被用来管理游戏资产，使得游戏资产的交易更加安全、透明和自动化。例如，在游戏平台上，智能合约可以自动处理游戏资产的交易、转移和存储等信息，从而保护游戏玩家的利益和游戏平台的安全。 78 | 79 | 2、游戏竞技管理 80 | 81 | 智能合约可以被用来管理游戏竞技，使得游戏竞技更加公平、高效和自动化。例如，在游戏竞技平台上，智能合约可以自动处理比赛的规则、奖励和惩罚等信息，从而提高游戏竞技的公平性和竞技效率。 82 | 83 | 以下是100个智能合约的应用场景： 84 | 85 | 1. 数字货币交易 86 | 2. 资产管理 87 | 3. 供应链管理 88 | 4. 物流管理 89 | 5. 食品安全追溯 90 | 6. 版权管理 91 | 7. 知识产权保护 92 | 8. 电子投票 93 | 9. 电子签名 94 | 10. 电子合同 95 | 11. 区块链游戏 96 | 12. 众筹 97 | 13. 慈善捐赠 98 | 14. 保险理赔 99 | 15. 金融衍生品交易 100 | 16. 货币兑换 101 | 17. 贸易融资 102 | 18. 货物质量检验 103 | 19. 物联网设备管理 104 | 20. 物联网数据交易 105 | 21. 网络安全监控 106 | 22. 人才招聘 107 | 23. 人事管理 108 | 24. 教育认证 109 | 25. 医疗数据管理 110 | 26. 医疗保险理赔 111 | 27. 交通违章处理 112 | 28. 电子身份认证 113 | 29. 物业管理 114 | 30. 公共服务管理 115 | 31. 政务管理 116 | 32. 物品租赁 117 | 33. 二手交易 118 | 34. 软件授权管理 119 | 35. 软件开发协议 120 | 36. 云计算资源管理 121 | 37. 人脸识别 122 | 38. 自动售货机管理 123 | 39. 智慧城市管理 124 | 40. 环境监测 125 | 41. 资源共享 126 | 42. 物理资产管理 127 | 43. 知识管理 128 | 44. 知识共享 129 | 45. 网络广告管理 130 | 46. 网络游戏交易 131 | 47. 电子商务交易 132 | 48. 物流运输管理 133 | 49. 退税管理 134 | 50. 企业融资 -------------------------------------------------------------------------------- /Public_Chain_Development/Public_Chain_Research/Ethereum/论文.md: -------------------------------------------------------------------------------- 1 | - Qin, Zhou, Gervais 论文：量化 [MEV](https://arxiv.org/pdf/2101.05511.pdf) 2 | - Werner, Perez, et al, 论文：[DeFi 知识的系统化](https://arxiv.org/abs/2101.08778) 3 | 4 | - [如何用多项式承诺打造 SNARKs](https://vitalik.ca/general/2021/01/26/snarks.html) 5 | - [验证密码学实现 constant-timeness 属性的工具的现状](https://neuromancer.sk/article/26) 6 | - Kyber 论证[动态 AMMs](https://files.kyber.network/DMM-Feb21.pdf)（弹性手续费和定价曲线）的论文 7 | - Vitalik：[牢不可破的多项式承诺是如何工作的](https://twitter.com/VitalikButerin/status/1371844878968176647) 8 | 9 | - [可聚合密钥的分布式生成](https://www.benthamsgaze.org/2021/03/24/aggregatable-distributed-key-generation/) 10 | - MatterLabs 正在计划一种[链下数据可得性](https://learnblockchain.cn/article/2405)安全模型 11 | - Dankrad Feist 解释 [51% 攻击的作恶边界](https://dankradfeist.de/ethereum/2021/05/20/what-everyone-gets-wrong-about-51percent-attacks.html) 12 | - Vitalik：[区块链可扩展性的局限](https://vitalik.ca/general/2021/05/23/scaling.html) 13 | - [共用品问题即是协作问题](https://s.mirror.xyz/djByMntM2rQF4tqUISYS2MAO3oCfSWoOZSOpZjsYwaw) 14 | - [使用多项式承诺在链下聚合投票并在链上验证的设计](https://nikeshnazareth.github.io/vote-aggregation/) 15 | - Matthew Ball：[Metaverse 指南](https://www.matthewball.vc/the-metaverse-primer) 16 | - Vitalik：带有已知份额的 [M-of-N 密钥分割](https://ethresear.ch/t/m-of-n-secret-sharing-with-pre-known-shares/10074) 17 | - [可公开审计的 MPC 作为一项服务](https://arxiv.org/abs/2107.04248)：可以简洁地验证以及用作通用的启动设置 18 | - Barnabé: [Proposer-Builder Separation (PBS) 研究现状](https://barnabe.substack.com/p/pbs) 19 | - Reorg 在 post-SSF(single slot finality) LMD-GHOST 的[重组弹性与安全性](https://ethresear.ch/t/reorg-resilience-and-security-in-post-ssf-lmd-ghost/14164) 20 | - 高效的[BLS多签EVM证明](https://geometry.xyz/notebook/Optimized-BLS-multisignatures-on-EVM) 21 | - [MinRoot](https://eprint.iacr.org/2022/1626)：VDF 的候选顺序函数 22 | - [优化见证打包](https://lighthouse-blog.sigmaprime.io/optimising-attestation-packing.html)。Lighthouse 当前贪婪算法在52.3%的测试实例中产生了最优解，并在99.97%的测试实例中产生了离最优解5%以内的解 23 | 24 | - [块拍卖 vs 槽拍卖](https://mirror.xyz/0x03c29504CEcCa30B93FF5774183a1358D41fbeB1/CPYI91s98cp9zKFkanKs_qotYzw09kWvouaAa9GXBrQ) Proposer-Builder Separation (PBS) 25 | - Flashbots: [在SGX（Software Guard Extensions 提供可信计算环境）内运行Geth](https://writings.flashbots.net/geth-inside-sgx/) 26 | - James Prestwich：[MEV 社区历史](https://medium.com/@Prestwich/mev-c417d9a5eb3d) 27 | - [完全知识证明 (CK)](https://medium.com/initc3org/complete-knowledge-eecdda172a81)：使用 TEE 和挖矿 ASIC 防止泄密 28 | - 关于[快速摊销 KZG 证明的注意事项](https://eprint.iacr.org/2023/033) 29 | - [Gradual Dutch Auctions（渐进式荷兰拍卖会）](https://people.eecs.berkeley.edu/~ksk/files/GDA.pdf) [PDF] 可以修改为与激励兼容 30 | - [对 AI 原语进行基准 zk 证明](https://medium.com/@ModulusLabs/chapter-5-the-cost-of-intelligence-da26dbf93307)，使用证明生成时间和峰值证明者内存使用量的指标 31 | - [网络性能指标](https://ethresear.ch/t/approximating-user-welfare-and-surplus-with-transaction-data/14766)：产生的价值（福利）和用户获得的价值（盈余） 32 | - [Rollup 中继](https://hackmd.io/@echno/rollup-relay)，减少 PBS 中继中的信任假设 33 | - 用延迟披露、前包含列表或平行拍卖实现[抗审查](https://iyusufali.xyz/writings/inclusion-lists) 34 | - [最近最新消息驱动 GHOST](https://twitter.com/luca_zanolini/status/1628702750392344577)：同步动态可用，对有界异步周期具有弹性，建议替代 Gasper 的 LMD-GHOST 35 | - [简单单Slot最终性](https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920)提案，同步动态可用协议和最终性小工具 36 | - [订单流拍卖 (OFA)](https://frontier.tech/the-orderflow-auction-design-space)分析 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/签名/死磕密码学_ECDSA算法-2.md: -------------------------------------------------------------------------------- 1 | > 死磕密码学|ECDSA算法 2 | > 文章资料代码请star https://github.com/blockchainGuide/ 3 | 4 | ![u=1020757406,2710278676&fm=26&gp=0](https://tva1.sinaimg.cn/large/008eGmZEgy1gn80yxj5d7j30et08cjrr.jpg) 5 | 6 | ## 生成签名 7 | 8 | 假设 Alice 希望对消息$m$进行签名，所采用的椭圆曲线参数为$D=(p,a,b,G,n,h)$，对应的密钥对为$(k,Q)$，其中为公钥$Q$，$k$为私钥。 9 | 10 | Alice 将按如下步骤进行签名： 11 | 12 | 1. 产生一个随机数$d$，$1 \leq d \leq n-1$. （签名算法首先生成一个临时私公钥对，该临时密钥对用于计算 r 和 s 值。） 13 | 2. 计算$dG=(x_1,y_1)$，将$x_1$化为整数$\overline{x_1}$. 14 | 3. 计算$r=\overline{x_1} \ mod \ n$，若$r=0$，则转向第1步. （r 值为临时公钥的坐标 x 值） 15 | 4. 计算 $d^{-1} \ mod \ n$ 16 | 5. 计算哈希值$H(m)$，并将得到的比特串转化为整数 e 17 | 6. 计算$s=d^{-1}(e+kr) \ mod \ n$，若$s=0$，则转向第1步. 18 | 7. $(r,s)$即为 Alice 对消息的签名. 19 | 20 | ## 椭圆曲线签名验证 21 | 22 | 为验证 Alice 对消息 m 的签名$(r,s)$，Bob 需要得到 Alice 所用的椭圆曲线参数$D=(p,a,b,G,n,h)$以及 Alice 的公钥 Q。 23 | 24 | 步骤如下： 25 | 26 | 1. 验证 r 和 s 是区间$[1,n-1]$上的整数. 27 | 2. 计算$H(m)$并将其转化为整数 e. 28 | 3. 计算$w=s^{-1} \ mod \ n$ 29 | 4. 计算$u_1=ew \ mod \ n$以及$u_2=rw \ mod \ n$ 30 | 5. 计算$X=(x_1,y_1)=u_1G+u_2Q$ 31 | 6. 若$X=O$，则拒绝签名，否则将 X 的$x$坐标$x_1$转化为整数，并计$\overline{x_1}$算$v=\overline{x_1} \ mod \ n$ 32 | 7. 当且仅当$v=r$时，签名通过验证. 33 | 34 | ## 椭圆曲线签名正确性 35 | 36 | 要证明$v=r$，只需要证明$X=dG$即可。 37 | 38 | 证明步骤： 39 | 40 | 令：$C=u_1G + u_2Q = u_1G+u_2kG=(u_1+u_2k)G$ 41 | 42 | 将$u_1$、$u_2$带入：$C=(ew+rwk)G=(e+rk)wG=(e+rk)s^{-1}G$ 43 | 44 | 由$s=d^{-1}(e+kr) \mod n$得出$s^{-1}=d(e+kr)^{-1} \mod n$，带入： $C=(e+kr)d(d+kr)^{-1}G = dG$ 45 | 46 | ## 使用案例 47 | 48 | ```go 49 | func main() { 50 | //生成签名---- 51 | //声明明文 52 | message := []byte("hello world") 53 | //生成私钥 54 | privateKey, _ := ecdsa.GenerateKey(elliptic.P256(), rand.Reader) 55 | //生成公钥 56 | pub := privateKey.PublicKey 57 | //将明文散列 58 | digest := sha256.Sum256(message) 59 | //生成签名 60 | r, s, _ := ecdsa.Sign(rand.Reader, privateKey, digest[:]) 61 | //设置私钥的参数类型为曲线类型 62 | param := privateKey.Curve.Params() 63 | //获得私钥byte长度 64 | curveOrderByteSize := param.P.BitLen() / 8 65 | //获得签名返回值的字节 66 | rByte, sByte := r.Bytes(), s.Bytes() 67 | //创建数组 68 | signature := make([]byte, curveOrderByteSize*2) 69 | //通过数组保存了签名结果的返回值 70 | copy(signature[curveOrderByteSize-len(rByte):], rByte) 71 | copy(signature[curveOrderByteSize*2-len(sByte):], sByte) 72 | 73 | //验证---- 74 | //将明文做hash散列，为了验证的内容对比 75 | digest = sha256.Sum256(message) 76 | curveOrderByteSize = pub.Curve.Params().P.BitLen() / 8 77 | //创建两个整形对象 78 | r, s = new(big.Int), new(big.Int) 79 | //设置证书值 80 | r.SetBytes(signature[:curveOrderByteSize]) 81 | s.SetBytes(signature[curveOrderByteSize:]) 82 | 83 | //验证 84 | e := ecdsa.Verify(&pub, digest[:], r, s) 85 | if e == true { 86 | fmt.Println("success") 87 | } else { 88 | fmt.Println("failed") 89 | } 90 | } 91 | ``` 92 | 93 | ## 参考 94 | 95 | > https://mindcarver.cn 96 | > 97 | > https://juejin.cn/post/6844903671411671047 98 | > 99 | > https://juejin.cn/post/6844903882343071758 100 | > 101 | > http://read.pudn.com/downloads54/sourcecode/windows/188357/ECDSA%E7%AE%97%E6%B3%95%E5%AE%9E%E7%8E%B0%E5%8F%8A%E5%85%B6%E5%AE%89%E5%85%A8%E6%80%A7%E5%88%86%E6%9E%90.pdf 102 | > 103 | > https://zhuanlan.zhihu.com/p/94852431 104 | 105 | 106 | 107 | 108 | 109 | -------------------------------------------------------------------------------- /DApp_Development/合约基础/solidity_callcode.md: -------------------------------------------------------------------------------- 1 | ## Solidity 中的 Call 方法 2 | 3 | `call` 方法是 Solidity 中一个提供了低级别函数调用的方法。这意味着 `call` 方法可以在 Solidity 合约中调用外部合约的函数。这种方法相对于 `external` 可见性更加灵活，因为它可以动态地执行函数调用，而不用提前知道要调用哪个函数。在本文中，我们将详细介绍 Solidity 中的 `call` 方法及其应用场景、注意点和安全性。 4 | 5 | ### Solidity 中的 Call 用法 6 | 7 | 在 Solidity 中，`call` 方法允许将给定的字节数组作为函数参数传递，并将该函数调用发送到指定的合约地址。`call` 方法的语法如下： 8 | 9 | ```solidity 10 | (bool success, bytes memory returnData) = address.call(bytes memory data); 11 | ``` 12 | 13 | 请注意，在调用 `call` 方法时，必须将要调用的合约地址转换为 `address` 类型。如果调用成功，将返回一个布尔值 `success` 和一个类型为 `bytes` 的数据 `returnData`。 `success` 值指示调用是否成功，`returnData` 存储从调用中返回的字节数组。 14 | 15 | 同时，需要注意的是，在调用外部合约时，需要使用自己的 ETH 或者从当前合约地址发送的 ETH 来支付 GAS 费用。因为 Solidity 不能直接在合约之间传递 Ether，所以您需要使用 `call()` 带上 `value` 参数来发送 ETH。 16 | 17 | 下面是 Solidity 中调用 `call` 的示例： 18 | 19 | ```solidity 20 | pragma solidity ^0.8.0; 21 | 22 | contract Example { 23 | function callExternalContract(address externalContractAddress) public returns (bytes memory) { 24 | bytes memory data = abi.encodeWithSignature("myFunction(uint256)", 123); 25 | (bool success, bytes memory returnData) = externalContractAddress.call(data); 26 | require(success, "Call failed."); 27 | 28 | return returnData; 29 | } 30 | } 31 | ``` 32 | 33 | 在这个示例中，我们定义了一个名为 `callExternalContract` 的函数，该函数使用参数 `externalContractAddress` 作为传递给外部合约的目标地址。我们使用 `abi.encodeWithSignature` 帮助程序将调用数据打包为字节数组 `data`。 34 | 35 | 然后，我们调用 `call` 方法将此数据发送到外部合约地址。如果调用成功，该方法将返回 `success` 和 `returnData`，并且我们可以使用返回的 `returnData` 来处理外部合约执行的结果。 36 | 37 | ### Solidity 中 Call 方法的应用场景 38 | 39 | `call` 方法是 Solidity 中非常重要的方法之一，它允许我们从当前合约中动态地执行函数调用。这使得 Solidity 的智能合约更加灵活和可编程。下面是一些 `call` 方法的应用场景： 40 | 41 | - 与其他智能合约进行通信：使用 `call` 方法调用其他智能合约非常常见。例如，您可能希望从一个智能合约中调用另一个智能合约以执行某些操作。这是 defi 生态系统中使用最频繁的方法之一。 42 | - 链下查询：使用 `call` 方法调用 Oracle 等外部系统，这些系统不在区块链上。例如，您可能需要使用外部数据来帮助智能合约作出决策，那么您就需要执行对外部数据的查询。 43 | 44 | ### Solidity 中 Call 的注意事项 45 | 46 | 想要使用 `call` 方法时，我们需要注意以下几点： 47 | 48 | 1. 始终检查成功标志。 49 | 50 | 在 `call` 方法调用后，必须始终检查 `success` 值以确认函数调用是否成功。如果 `success` 的值为 false，可能是由于目标合约执行失败或者 `gas` 不足。如果没有检查 `success` 值，您的合约将依然运行，但是可能会执行其他不必要的行为。 51 | 52 | 2. 撤销攻击 (Reentrancy attack) 的风险 53 | 54 | 如果您使用 `call` 来执行外部函数调用，则必须注意该函数中是否包含了任何可以引起撤销攻击的代码。如何避免撤销攻击超出了本文的范围，但是这是使用 `call` 方法时需要注意的重要注意事项。在避免撤销攻击的过程中，`call` 中的 `msg.sender` 变量会被更新，确保它只表示当前合约的调用者。 55 | 56 | 3. 可能会超出 Gas 价格 57 | 58 | 在使用 `call` 方法时，必须注意 Gas 的限制。如果 `call` 方法使用的 Gas 太多，将导致它的执行被终止，并且将 Gas 视为 “消耗” 的操作将回滚。这可能会导致函数调用失败。要避免此类问题，您应该使用 `gas()` 函数来获取当前 Gas 限制，并检查 `call` 方法的成本是否超出了该限制。如果成本过高，则可以尝试增加 Gas 的限制或使用更简单的逻辑。此外，根据需要使用 `gas` 参数或 `estimateGas()` 函数来为 `call` 函数调用指定精确的 `gas` 用量和预估的 `gas` 用量。 59 | 60 | ### Solidity 中 Call 方法的安全性 61 | 62 | 尽管 `call` 方法强大而灵活，但是它也可以被不善意的第三方滥用。攻击者可以使用 `call` 方法来执行不当代码并引起重大损失。以下是几种常见的风险： 63 | 64 | 1. 奇怪的地址 65 | 66 | 如果您使用的合约地址来自不受信任的源，那么调用可能会被劫持并被重定向到攻击者的地址上。因此，当使用 `call` 向另一个合约发送 Ether 时，需要确保合约地址是合法的，且来自受信任的源。 67 | 68 | 2. 错误的函数调用 69 | 70 | `call` 函数的参数必须准确地匹配要调用的函数，否则将导致执行失败，这包括函数签名、参数类型和参数数量。因此，需要确保正确编写了 `call` 函数，并运行测试以确保它能够正常执行。 71 | 72 | 3. 恶意合约 73 | 74 | 可以轻松编写能够使用 `call` 逻辑结构的恶意合约，以便攻击其他的智能合约。因此，对于 `call` 方法，需要确保只使用来自受信任的源的合约地址，并对输入数据进行验证。 75 | 76 | ### 总结 77 | 78 | 本文提供了关于 Solidity 中 `call` 方法的详细信息。我们了解了该方法的用途、语法和应用程序，并介绍了使用该方法时需要注意的事项和安全性问题。最好的实践中将 `call` 与 Solidity 中的其他函数结合使用，以便从合约中调用其他合约或执行支持逻辑 的操作，同时确保安全性和正确性。在编写智能合约时，始终应该考虑问题的安全性和正确性。 -------------------------------------------------------------------------------- /Public_Chain_Development/Consensus_Mechanisms/istanbul共识源码分析.md: -------------------------------------------------------------------------------- 1 | ## handler.go （处理消息） 2 | 3 | ### start 4 | 5 | 1. startNewRound(common.Big0) 6 | 2. subscribeEvents() 7 | 3. handleEvents() 8 | - istanbul.RequestEvent{} 9 | - istanbul.MessageEvent{} 10 | - backlogEvent{} 11 | - timeoutEvent{} 12 | - istanbul.FinalCommittedEvent{} 13 | 14 | ### stop 15 | 16 | 1. roundChangeTimer.Stop() 17 | 2. unsubscribeEvents() 18 | - events.Unsubscribe()timeoutSub.Unsubscribe() 19 | - finalCommittedSub.Unsubscribe() 20 | 3. 使得handler处于wait状态 21 | 22 | ### handleMsg&handleTimeoutMsg 23 | 24 | 25 | 26 | 1. 先进行msg的check 27 | 2. 如果是futureMsg，直接存储并returnErr 28 | 3. 接下来处理4个msg 29 | 30 | 31 | ## startNewRound 32 | 33 | 1. 首先设置roundChange 为false，如果最新的proposer和proposal不存在，直接return 34 | 35 | 2. 第二个步骤有几个if else 需要拆解（TODO） 36 | 37 | 3. 如果roundChange为true，新建一个View，如果为false，sequence加1 38 | 39 | 4. 选出proposer（CalcProposer），根据valset、lastprotser、round进行选择 40 | 41 | 5. 设置状态为接收请求c.setState(StateAcceptRequest)。 42 | 43 | - 发送istanbul.RequestEvent（把proposal扔出去） 44 | - 处理积压消息（Preprepare） 45 | - 发送backlogEvent事件 46 | - endPreprepare： 47 | 48 | - 如果自己是proposer并且和proposal有着相同的sequence，那就广播preprepare消息 49 | - 广播途中将消息转换成payload 并返回 50 | 51 | 52 | 53 | ## handlePreprepare 54 | 55 | 56 | 57 | - 校验message ，如果是老的prepare消息，要commit 这个proposal,直接会到广播comiit消息 58 | - 校验消息来自当前的proposer 59 | - 校验我们接收到的proposal 60 | - check 坏块 61 | - check block body(rehash) 62 | - verifyHeader (TODO,重点了解) 63 | - 校验之后，（TODO，逻辑？） 64 | 65 | 6. 如果锁定的proposal和接收到的proposal不一致就sendNextRoundChange，如果一样，就接收prepare消息并设置状态为StatePreprepared并且发送commit消息 66 | 67 | 68 | 69 | ## handleCommit 70 | 71 | 1. checkMessage 72 | 2. verifyCommit 73 | 3. acceptCommit(添加到commits中) 74 | 4. 有了足够的commit messages并且不是comiited状态将commit proposal 75 | 5. Commit 76 | - 设置状态为comitted 77 | - 创建commitSeals 78 | - 进入最终的commit代码 79 | - 校验proposal是一个有效块 80 | - seals写入到extra-data中（writeCommittedSeals 关键代码） 81 | - 更新block的header 82 | - 如果proposedBlockHash == commitedBlockHash ,那么就把block 扔到commitCh中去seal并且等待seal结果（这是proposer才会走的通道），直接返回；如果不一样，直接塞入到enqueue中（sb.broadcaster.Enqueue(fetcherID, block)） 83 | 84 | ## handleRoundChange 85 | 86 | 1. checkMessage 87 | 2. roundChangeSet 添加消息 88 | 3. 只要达到了F+1个roundChange就构成了一个weak proof ,就可以检查此时的round是否比我们的round小，如果小就CatchUp,然后startNewRound（需要2F+1） 89 | 90 | 91 | 92 | ## engine.go 93 | 94 | ### prepare 95 | 96 | 准备header 97 | 98 | 1. sb.snapshot 99 | 100 | 2. 从candidates中随机设置coinbase 101 | 102 | 3. prepareExtra（将快照中的validators添加到extraData的validators中），payload 数据就是编码后的IstanbulExtra，作为extra 103 | 104 | > ```go 105 | > types.IstanbulExtra{ 106 | > Validators: vals, 107 | > Seal: []byte{}, 108 | > CommittedSeal: [][]byte{}, 109 | > } 110 | > ``` 111 | 112 | 113 | 114 | ### FinalizeAndAssemble 115 | 116 | 运行交易后状态更改，组装成最终的block 117 | 118 | 119 | 120 | ### seal 121 | 122 | 生成一个新块放入给定通道 123 | 124 | 1. 主块判断是否是validator，子链还必须判断是不是子validator 125 | 2. 更新块（updateBlock），proposer用自己的私钥给块签名生成seal，并写入IstanbulExtra的seal中，包括自己的签名的标记和其他人签名的标记，其实就是返回带签名的块 126 | 3. 把块丢到共识引擎中，通过事件istanbul.RequestEvent传播，从而进入到handleRequest，开启sendPrepeare，result等待的就是sb.commitCh中的数据 -------------------------------------------------------------------------------- /DApp_Development/合约基础/solidity_call.md: -------------------------------------------------------------------------------- 1 | Solidity 中的 `call` 函数是一种低级别的函数调用方式，它允许智能合约在用于与其他合约进行交互时具有更高的灵活性。本文将详细介绍 Solidity 中的 `call` 函数，包括其语法、用法、应用场景、注意点和安全性。 2 | 3 | ## 语法 4 | `call` 函数的语法如下： 5 | 6 | ``` 7 | (bool success, bytes memory returnData) = address.functionName{value: amount}(arguments); 8 | ``` 9 | 10 | 其中： 11 | 12 | - `bool success`：标志函数调用是否成功。 13 | - `bytes memory returnData`：包含函数调用结果的字节数组（返回值）。 14 | - `address`：要调用的合约地址。 15 | - `functionName`：要调用的函数名。 16 | - `value: amount`：可选的转移金额（以 wei 为单位），用于向目标合约转移 ether。 17 | - `arguments`：传递给目标函数的参数。 18 | 19 | `call` 函数的返回值包含两个部分：`bool success` 和 `bytes memory returnData`。如果函数调用成功，则 `success` 为 `true`，否则为 `false`。`returnData` 包含函数调用的返回值或错误信息。需要注意的是，由于 Solidity 不支持重载函数，因此 `functionName` 只能是被调用函数的确切名称，而不能是同名函数的不同版本。 20 | 21 | ## 用法 22 | 23 | `call` 函数广泛应用于 Solidity 合约中，以便执行以下操作： 24 | 25 | 1. 调用其他合约的函数。 `call` 函数允许合约在其他合约中调用函数，而不需要事先知道其他合约中函数的实现细节。 这是因为调用方不需要知道其他合约的源代码，只需要知道它的地址和函数签名即可。在这种情况下，`call` 函数可以返回目标合约函数的输出或错误信息。 26 | 27 | 以下是一个示例，该示例调用另一个合约的 `balanceOf` 函数来获取给定地址的 ETH 余额： 28 | 29 | ```Solidity 30 | pragma solidity ^0.8.3; 31 | 32 | contract MyContract { 33 | function getBalance(address _token, address _address) external view returns(uint256) { 34 | (bool success, bytes memory data) = _token.call(abi.encodeWithSignature("balanceOf(address)", _address)); 35 | require(success, "Failed to get balance"); 36 | return abi.decode(data, (uint256)); 37 | } 38 | } 39 | ``` 40 | 41 | 在上述代码中，`call` 函数调用了 `_token` 合约的 `balanceOf` 函数，并将 `_address` 作为参数传递给该函数。如果调用成功，则函数将返回给定地址 `_address` 在 `_token` 合约中的 ETH 余额。 42 | 43 | 2. 向其他合约发送 ETH。 合约可以使用 `call` 函数向其他合约发送 ETH。发生此操作时，合约需要设置在发送交易时要转移的以太币金额。在这种情况下，`call` 函数可以返回接收方合约中的状态或错误信息。 44 | 45 | 以下是一个示例，该示例向另一个合约发送 ETH，然后从该 contracts 合约中检索余额并确保已正确收到 ETH： 46 | 47 | ```Solidity 48 | pragma solidity ^0.8.3; 49 | 50 | contract MyContract { 51 | function sendEth(address payable _to) external payable { 52 | (bool success,) = _to.call{value: msg.value}(abi.encodeWithSignature("dummy()")); 53 | require(success, "Failed to send ether"); 54 | } 55 | } 56 | 57 | contract OtherContract { 58 | mapping (address => uint256) public balances; 59 | 60 | constructor() payable {} 61 | 62 | receive() external payable { 63 | balances[msg.sender] += msg.value; 64 | } 65 | 66 | function dummy() external {} 67 | } 68 | ``` 69 | 70 | 在上述代码中，`MyContract` 合约中的 `sendEth` 函数使用 `call` 函数向 `OtherContract` 合约发送 ETH。`value: msg.value` 设置将要转移的以太币数量。 接着，`receive` 函数会接收传入的 ETH 并将其余额添加到余额映射中。最后，我们可以使用 `balances` 映射来检索一个地址在 `OtherContract` 合约中的余额。 71 | 72 | ## 应用场景 73 | 74 | 以下是几个 Solidity 中使用 `call` 函数的常见应用场景： 75 | 76 | 1. 委托合约实现。 智能合约可以将某些操作委托给其他智能合约来执行。这可能是因为合约调用者没有当前的权限或信息，或者因为合约不希望直接执行某些操作。在这种情况下，合约可以使用 `call` 函数调用另一个合约以执行操作，并可选地接收调用结果。 77 | 78 | 2. ERC-20 标准。许多 ERC-20 代币都是作为智能合约实现的，并使用 `call` 函数在其他合约中转移代币。这是因为 ERC-20 代币标准规定了需要包含的函数名称和参数，并指定了传递给以太坊的代币信息的格式。 79 | 80 | 3. 钱包管理。 在钱包 Dapps 中，用户使用智能合约来管理其加密货币，例如以太币和 ERC-20 代币。在这种情况下，合约需要使用 `call` 函数与以太坊主链和其他合约进行交互，并执行必要的功能，例如存储加密货币余额和合约操作。 81 | 82 | ## 注意点和安全性 83 | 84 | 在使用 `call` 函数时，存在以下注意点和安全性问题： 85 | 86 | 1. 可能遭受恶意攻击。由于底层代码在运行之前不会检查它们的输入或输出数据，因此可能会导致合约受到各种安全攻击。在使用 `call` 函数时，请通过分析目标合约的源代码和源码可靠性来验证其安全性。 87 | 88 | 2. `call` 函数可能会消耗更多的 Gas。由于 `call` 是 Solidity 中的低级函数，因此需要更多的 Gas 来执行。如果使用过多的 `call` 函数，可能会使合约变得不可用，因为它可能超过了以太坊当前块的 Gas 限制。 89 | 90 | 3. 需要对错误进行检查。在使用 `call` 函数后，始终需要检查返回的值以确保调用成功。否则，您可能会遇到信息泄漏和其他安全问题。 91 | 92 | 总之，`call` 函数是 Solidity 中非常有用的低级函数之一，并在智能合约的开发过程中被广泛使用。但是，在使用之前需要仔细考虑一些问题，并遵循最佳实践，以确保程序的安全和有效性。 -------------------------------------------------------------------------------- /Public_Chain_Development/Cryptography/隐私计算/VDF/VDF.md: -------------------------------------------------------------------------------- 1 | # 可延迟函数（VDF）研究 2 | 3 | ## 摘要 4 | 5 | 本文旨在对可延迟函数（VDF）进行全面的研究。VDF是一种具有可验证输出且固定计算时间的函数。本文将详细介绍VDF的概念、原理、安全性和应用场景。我们还将对现有的VDF构造方法和实现进行评估，并讨论VDF在密码学和分布式系统领域的未来发展趋势。 6 | 7 | ## 目录 8 | 9 | 1. 引言 10 | 2. VDF的定义和概念 11 | 3. VDF的原理 12 | 4. VDF的安全性 13 | 5. VDF的构造方法 14 | 1. RSA VDF 15 | 2. 指数VDF 16 | 3. 其他VDF构造方法 17 | 6. VDF的实现和优化 18 | 7. VDF的应用场景 19 | 1. 区块链共识算法 20 | 2. 密码学抽奖 21 | 3. 时间戳服务 22 | 4. 其他应用 23 | 8. VDF的未来发展趋势 24 | 9. 总结 25 | 26 | ## 1. 引言 27 | 28 | 可延迟函数（VDF）是一种具有内在延迟性质的密码学函数。与普通函数相比，VDF在计算结果时需要消耗一定的时间，并且这个时间无法通过提高计算资源来缩短。VDF的一个重要特性是其输出具有可验证性，这意味着任何人都可以在较短的时间内验证VDF的计算结果。VDF因其独特的特性而在密码学和分布式系统领域备受关注。 29 | 30 | ## 2. VDF的定义和概念 31 | 32 | VDF是一种函数`F`，具有以下性质： 33 | 34 | - **固定计算时间**：计算`F(x)`需要消耗一个固定的时间`t`，这个时间无法通过提高计算资源来缩短。 35 | - **唯一性**：对于同一输入`x`，`F(x)`的输出是唯一的。 36 | - **可验证性**：给定输入`x`和输出`y`，任何人都可以在较短的时间内验证`y = F(x)`。 37 | 38 | ## 3. VDF的原理 39 | 40 | VDF的原理是基于计算难解性假设。VDF利用了一些困难问题（如模指数、离散对数等）的计算难度来实现固定的计算时间。这些问题的解决需要消耗一定的计算资源和时间，而计算过程无法在固定时间内通过并行化或其他优化手段加速。在设计VDF时，需要确保满足唯一性和可验证性的要求。 41 | 42 | ## 4. VDF的安全性 43 | 44 | VDF的安全性取决于其底层的计算难解性假设。为了实现安全的VDF，我们需要选择一个在现有计算技术下难以攻破的困难问题。在评估VDF安全性时，我们需要关注以下几个方面： 45 | 46 | - **攻击者模型**：针对不同类型的攻击者，VDF需要提供相应级别的安全性。例如，在面对拥有量子计算资源的攻击者时，VDF可能需要采用量子抗攻击的困难问题。 47 | - **攻击方法**：需要分析和防范针对VDF的各种攻击方法，如暴力破解、时间回绕攻击等。 48 | - **参数选择**：VDF的参数选择直接影响其安全性。例如，选择过小的模数可能导致VDF的输出容易被攻击者破解。 49 | 50 | ## 5. VDF的构造方法 51 | 52 | 目前，已经有多种VDF构造方法被提出。以下是一些主要的VDF构造方法： 53 | 54 | ### 5.1 RSA VDF 55 | 56 | RSA VDF是基于RSA体系的VDF构造方法。它利用了模指数问题的计算难度来实现固定的计算时间。RSA VDF的计算过程涉及大整数模指数运算，而验证过程则利用了RSA模数的特性来加速。 57 | 58 | ### 5.2 指数VDF 59 | 60 | 指数VDF是基于离散对数问题的VDF构造方法。它利用了椭圆曲线或有限域上的离散对数问题的计算难度来实现固定的计算时间。指数VDF的计算过程涉及连续的椭圆曲线点加法或有限域乘法运算，而验证过程则利用了配对技术来加速。 61 | 62 | ### 5.3 其他VDF构造方法 63 | 64 | 除了上述两种VDF构造方法外，还有一些其他基于不同计算难解性假设的VDF构造方法。这些构造方法可能在某些特定场景下具有优势，如更高的计算效率、更强的安全性等。 65 | 66 | ## 6. VDF的实现和优化 67 | 68 | 在实现VDF时，我们需要关注以下几个方面： 69 | 70 | - **效率**：VDF的计算和验证过程需要尽可能高效。这可能涉及到算法优化、硬件加速等技术。 71 | 72 | - **可扩展性**：VDF应该能够在大规模系统中使用，支持多个参与者的并行计算和验证。 73 | 74 | - **通用性**：VDF实现应该能够适应不同场景的需求，包括不同的安全级别、计算资源限制等。 75 | - **兼容性**：VDF实现应该尽可能兼容现有的密码学库和硬件设备，以便在实际项目中快速集成。 76 | 77 | 在实现VDF时，可能需要采用多种优化策略，如： 78 | 79 | - **算法优化**：通过优化算法来减少计算和验证的时间复杂度。 80 | - **并行化**：在多核处理器或多个处理器之间分配计算任务，以提高计算效率。 81 | - **硬件加速**：利用专用硬件设备（如GPU、ASIC等）加速计算和验证过程。 82 | - **预计算**：在计算VDF时，可以预先计算并存储一些中间结果，以减少实时计算的开销。 83 | 84 | ## 7. VDF的应用场景 85 | 86 | VDF因其独特的性质在多个领域具有广泛的应用潜力。以下是一些主要的应用场景： 87 | 88 | ### 7.1 区块链共识算法 89 | 90 | 在区块链共识算法中，VDF可以作为一种随机性源来确保选举过程的公平性。例如，在Proof-of-Stake（PoS）共识算法中，VDF可以防止验证者通过提前预测随机数来操纵选举结果。 91 | 92 | ### 7.2 密码学抽奖 93 | 94 | VDF可以应用于密码学抽奖，确保抽奖过程的公平性和不可预测性。通过使用VDF，可以防止参与者在抽奖过程中作弊或预测中奖结果。 95 | 96 | ### 7.3 时间戳服务 97 | 98 | VDF可以用于构建可验证的时间戳服务。通过将时间戳和数据作为VDF的输入，可以生成一个具有可验证性的输出。任何人都可以通过验证VDF输出来确保数据在指定时间之前存在。 99 | 100 | ### 7.4 其他应用 101 | 102 | VDF还可以应用于其他需要随机性和延迟性质的场景，如分布式计算、在线竞赛、加密货币挖矿等。 103 | 104 | ## 8. VDF的未来发展趋势 105 | 106 | 随着密码学和分布式系统领域的发展，VDF可能会出现更多的应用场景和新的构造方法。未来的研究可能会关注以下方面： 107 | 108 | - **新的VDF构造方法**：基于新的计算难解性假设和密码学技术，可能会出现更高效、更安全的VDF构造方法。 109 | - **量子抗攻击VDF**：随着量子计算的发展，传统的VDF可能会受到量子攻击的威胁。未来的研究需要探索基于量子抗攻击计算难解性假设的VDF构造方法。 110 | - **VDF的可扩展性和并行性**：随着大规模系统和多核处理器的普及，提高VDF的可扩展性和并行性将成为一个重要的研究方向。 111 | - **VDF与其他密码学原语的结合**：VDF可以与其他密码学原语（如零知识证明、同态加密等）结合，实现更丰富的功能和应用场景。 112 | - **硬件实现和优化**：随着专用硬件设备（如ASIC、FPGA等）的发展，VDF的硬件实现和优化将成为一个有前景的研究领域。 113 | 114 | ## 9. 总结 115 | 116 | 本文对可延迟函数（VDF）进行了全面的研究。我们介绍了VDF的概念、原理、安全性和应用场景，并对现有的VDF构造方法和实现进行了评估。最后，我们讨论了VDF在密码学和分布式系统领域的未来发展趋势。随着VDF技术的进一步发展，我们期待它在更多场景中发挥重要作用，为构建更安全、更公平的分布式系统提供支持。 -------------------------------------------------------------------------------- /Public_Chain_Development/Consensus_Mechanisms/死磕共识算法_pow算法-1.md: -------------------------------------------------------------------------------- 1 | > 死磕共识算法|pow算法 2 | > 3 | > 配合以下代码进行阅读：https://github.com/blockchainGuide/ 4 | > 5 | > 写文不易，给个小关注，有什么问题可以指出，便于大家交流学习。 6 | 7 | ![f1](https://tva1.sinaimg.cn/large/008eGmZEgy1gn80djrtwej30d606tmxc.jpg) 8 | 9 | # 概述 10 | 11 | 工作量证明(`Proof Of Work`，简称`POW`)，简单理解就是一份证明，用来确认你做过一定量的工作。监测工作的整个过程通常是极为低效的，而通过对工作的结果进行认证来证明完成了相应的工作量，则是一种非常高效的方式。比如现实生活中的毕业证、驾驶证等等，也是通过检验结果的方式（通过相关的考试）所取得的证明。 12 | 13 | 工作量证明系统（或者说协议、函数），是一种应对拒绝服务攻击和其他服务滥用的经济对策。它要求发起者进行一定量的运算，也就意味着需要消耗计算机一定的时间。这个概念由**Cynthia Dwork** 和**Moni Naor** 1993年在学术论文中首次提出。而工作量证明（`POW`）这个名词，则是在 1999 年 **Markus Jakobsson** 和**Ari Juels**的文章中才被真正提出。 14 | 15 | # 主流POW共识使用的哈希算法 16 | 17 | 实际不同的`POW`共识的核心就是**不同的哈希算法**，已经有很多`Hash`函数被设计出来并广泛应用，不过Hash函数一般安全寿命都不长，被认为安全的算法往往没能使用多久就被成功攻击，新的更安全的算法相继被设计出来，而每一个被公认为安全可靠的算法都有及其严格的审计过程。在币圈中我们经常说某某币发明了某种算法，其实主要都是使用那些被认证过的安全算法，或是单独使用，或是排列组合使用。 18 | 19 | ## SHA256 20 | 21 | `SHA-2`，名称来自于安全散列算法2（英语：`Secure Hash Algorithm 2`）的缩写，一种密码散列函数算法标准，由美国国家安全局研发，属于`SHA`算法之一，是`SHA-1`的后继者。`SHA-2`下又可再分为六个不同的算法标准。包括了：`SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256。` 22 | 23 | 具体的算法解释请查看此文：[区块链技术栈全景分析](https://github.com/blockchainGuide) 24 | 25 | ## SCRYPT 26 | 27 | `Scrypt`是内存依赖型的`POW`算法，莱特币采用此算法。第一个使用`Scrypt`算法的数字货币是`Tenebrix`，而后该算法被**莱特币**使用。莱特币创始人在莱特币创世帖中介绍了莱特币采用的共识机制，挖矿算法，发行总量，挖矿难度等相关重要信息。李启威说明了莱特币所使用的挖矿算法为数字货币`Tenebrix`所使用的`Scrypt`算法，是一种符合`PoW`共识机制的算法。`Scrypt`算法过程中也需要计算哈希值，但是，`Scrypt`计算过程中需要使用较多的内存资源。 28 | 29 | 其它使用Scrypt算法的数字货币还有数码币（`DigitalCoin`）、狗狗币（`DogeCoin`）、幸运币（`LuckyCoin`）、世界币（`WorldCoin`）等。 30 | 31 | 算法实现：https://www.imooc.com/article/50372 32 | 33 | 34 | 35 | ## 串联算法 36 | 37 | 重新排列组合是人类一贯以来最常用的创新发明方法。很快，有人不满足于使用单一`Hash`函数，2013年7月，夸克币（`Quark`）发布，首创使用多轮`Hash`算法，看似高大上，其实很简单，就是对输入数据运算了9次`hash`函数，前一轮运算结果作为后一轮运算的输入。这9轮Hash共使用6种加密算法，分别为`BLAKE, BMW, GROESTL, JH, KECCAK和SKEIN`，这些都是公认的安全`Hash`算法，并且早已存在现成的实现代码。 38 | 39 | 这种多轮Hash一出现就给人造成直观上很安全很强大的感觉，追捧者无数。现今价格依然坚挺的达世币率先使用11种加密算法（`BLAKE, BMW, GROESTL, JH, KECCAK, SKEIN, LUFFA, CUBEHASH, SHAVITE, SIMD, ECHO`），美其名曰X11，紧接着X13，X15这一系列就有人开发出来了。 40 | 41 | S系列算法实际是一种串联思路，只要其中一种算法被破解，整个算法就被破解了，好比一根链条，环环相扣，只要其中一环断裂，整个链条就一分为二。 42 | 43 | 44 | 45 | ## 并联算法 46 | 47 | `Heavycoin（HVC）`是第一个做了尝试的并联算法，其原理如下： 48 | 49 | 1. 对输入数据首先运行一次`HEFTY1`（一种`Hash`算法）运算，得到结果d1 50 | 2. 以`d1`为输入，依次进行`SHA256`、`KECCAK512`、`GROESTL512`、`BLAKE512`运算，分别获得输出`d2`,`d3`,`d4`和`d5` 51 | 3. 分别提取`d2-d5`前64位，混淆后形成最终的`256`位Hash结果，作为区块ID。 52 | 53 | ![image-20210202134353334](https://tva1.sinaimg.cn/large/008eGmZEgy1gn950ksww1j31e60fetfh.jpg) 54 | 55 | 之所以首先进行一轮`HEFTY1` 哈希，是因为HEFTY1 运算起来极其困难，其抵御矿机性能远超于`SCRYPT`。但与`SCRYPT`一样，安全性没有得到某个官方机构论证，于是加入后面的四种安全性已经得到公认的算法增强安全。 56 | 57 | 对比串联和并联的方法，`Quark、X11，X13`等虽使用了多种`HASH`函数，但这些算法都是简单的将多种`HASH`函数串联在一起，仔细思考，其实没有提高整体的抗碰撞性，其安全性更是因木桶效应而由其中安全最弱的算法支撑，其中任何一种`Hash`函数遭遇碰撞性攻击，都会危及货币系统的安全性。 58 | 59 | `HVC`从以上每种算法提取`64`位，经过融合成为最后的结果，实际上是将四种算法并联在一起，其中一种算法被破解只会危及其中`64`位，四中算法同时被破解才会危及货币系统的安全性。 60 | 61 | ## ETHASH 62 | 63 | Ethash是以太坊上面使用的POW算法，具体的介绍可以查看此文（**建议关注此公号**）：[死磕以太坊源码分析之ETHASH算法](https://mp.weixin.qq.com/s?__biz=MzU2MjY5MzcyMQ==&mid=2247484167&idx=1&sn=1cbec62883c0200c7be39e6986cd53e4&scene=19#wechat_redirect) 64 | 65 | 66 | 67 | # POW算法存在的问题 68 | 69 | 1. 算力竞争的设计导致了集中化的矿池：尽管PoW的目的是为了保证系统可以去中心化的运行，然而系统运行到现在，却事实上形成中心化程度很高的五大矿池。五大矿池垄断了世界上90%以上的算力，这可能导致大矿池破坏整个网络的行为 70 | 2. 算力竞争的设计导致了大量的能源消耗： 另外，PoW系统需要产生大量的能源消耗：比特币挖矿比159个国家消耗的能源还多；目前77.7%的全球比特币网络算力仍在中国境内；受益于内蒙古和四川两地充沛的电力资源，中国拥有世界上最多的比特币矿场；到2019年7月，比特币网络将需要比美国目前的用电量更多的电力；到2020年2月，它将使用和今天全世界一样多的电力 71 | 3. 业务处理性能低下：尽管投入了大量的能源支持系统的运行，但这些能源消耗绝大部份是用于工作量证明中的hash运算，处理交易业务的性能则非常低，例如比特币每秒只能进行大约7笔交易；以太坊每秒10-20笔。 72 | 73 | # 参考 74 | 75 | > https://web.xidian.edu.cn/qqpei/files/Blockchain/2Crypto.pdf --------------------------------------------------------------------------------