基础漏洞总结1
之前学的比较乱，现在复习整理一下。 重入re-entrancy重入攻击是指在合约执行外部调用（通常是向外发送以太或调用另一个合约）时，接收方在该外部调用的执行流程中再次调用回原合约的某个函数，并借此在原合约未完成状态更新之前重复利用其尚未更新的状态，从而盗取资金或破坏状态一致性。 换句话说：合约 A 在执行到“对外调用”并等待返回时，被外部合约 B 回调回 A，利用 A 尚未完成的内部逻辑（比如余额未清零）重复触发受害逻辑。 示例漏洞合约 12345678910111213141516171819202122232425262728293031323334// SPDX-License-Identifier: MITpragma solidity ^0.8.0;contract EtherStoreVulnerable { uint256 public withdrawalLimit = 1 ether; mapping(address => uint256) public lastWithdrawTime; mapping(address...
关于Git 子模块（子文档）
问题发现&解决什么是子模块（子文档） 定义：Git 子模块（submodule）是一个嵌套在父仓库中的独立 Git 仓库。 作用：允许你在一个 Git 仓库中引用另一个仓库，并保持独立版本控制。 特点： 有自己的 .git 目录或由父仓库 .gitmodules 管理。 GitHub 上显示为 箭头文件夹，点击会跳转到子模块的远程仓库。 本地未初始化或更新时，会出现 in unpopulated submodule 报错。 如何发现文件夹被上传成子模块 GitHub 文件浏览器： 文件夹前有 箭头标记。 点击会跳到子模块对应的远程仓库，而不是显示普通文件列表。 本地操作： 执行 git status 或 git submodule status 可能显示子模块信息。 对未初始化的子模块操作文件会报错，例如： 1in unpopulated submodule 为什么文件夹会被识别为子模块 误操作添加子模块： 1git submodule add <repo_url> 子文件夹名 Git 会记录子模块信息在 .gitmodules...
分布式详解2
ZAB协议ZAB协议定义ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议，实现分布式数据一致性。 ZAB协议组成部分消息广播 集群中所有的事务请求都由Leader节点来处理，其他服务器为Follower Leader将客户端的事务请求转换为事务Proposal，并且将Proposal分发给集群中其他所有的Follower 完成广播之后，Leader等待Follower反馈，当有过半数的Follower反馈信息后，Leader将再次向集群内Follower广播Commit信息 Commit信息就是确认将之前的Proposal提交 Leader节点的写入是一个两步操作：第一步是广播事务操作，第二步是广播提交操作 过半数指的是反馈的节点数 >=N/2+1，N是全部的Follower节点数量 崩溃恢复 在以下情况下会进入崩溃恢复模式： 初始化集群，刚刚启动的时候 Leader崩溃，因为故障宕机 Leader失去了半数的机器支持，与集群中超过一半的节点断连 此时开启新一轮Leader选举，选举产生的Leader会与过半的...
分布式详解1
CAP理论简述CAP理论 **数据一致性 (Consistency)**：如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据。对调用者而言数据具有强一致性。 **服务可用性 (Availability)**：所有读写请求在一定时间内得到响应，可终止、不会一直等待。 **分区容错性 (Partition Tolerance)**：在网络分区的情况下，被分解的节点仍能正常对外服务。 如果选择了CA而放弃了P，那么当发生分区现象时，为了保证C，系统需要禁止写入，当有写入请求时，系统返回error，这又和A冲突了，因为A要求返回no error和no timeout。因此，分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。 反证：如果CAP三者可同时满足，由于允许P的存在，则一定存在节点之间的丢包，如此则不能保证C。因为允许分区容错，写操作可能在节点1上成功，在节点2上失败，这时候对于Client1（读取节点1）和Client2（读取节点2），就会读取到不一致的值，出现不一致的情况。如果要保持一致性，写操作必...
nvm 是如何在操作系统文件层面管理 Node.js 版本的？
nvm 是如何在操作系统文件层面管理 Node.js 版本的？很多人知道 nvm（Node Version Manager）可以一键切换 Node.js 版本，但它到底是如何在系统文件层做到“多版本共存、快速切换”的呢？下面用简单易懂的方式带你了解。 核心思路：把不同版本放在不同文件夹里nvm 不会把 Node.js 安装在系统默认目录（比如 /usr/local/bin 或 C:\Program Files），而是放到它自己的目录下。例如： 在 Linux / macOS：1234~/.nvm/versions/node/ ├── v14.21.3/ ├── v16.20.0/ └── v18.17.1/ 在 Windows（nvm-windows）：1234D:\Program Files\nvm\ ├── v14.21.3\ ├── v16.20.0\ └── v18.17.1\ 每个版本都有一套完整的 Node 和 npm 文件，不互相覆盖。 一、切换版本时做了什么？当你运行： 1nvm use 16 nvm 的操作...
代码理解记录1
1uint id = zombies.push(Zombie(_name, _dna)) - 1; 错误理解：仅记录加入数组的僵尸的下标 正确理解：1. 创建一个 Zombie 结构体实例1Zombie(_name, _dna) 这是对 Zombie 结构体的构造（只是内存中的一个临时对象）。 2. 调用 zombies.push(...) 将它加入数组1zombies.push(...) push 会把这个新的僵尸放入 zombies 动态数组中，并且返回当前数组的新长度。 3. 计算该僵尸的下标（ID）因为 push 返回的是「数组新长度」，所以减 1 就是索引： 1uint id = ... - 1; 该代码等价于： 12zombies.push(Zombie(_name, _dna)); // 加入数组uint id = zombies.length - 1; // 获取下标
V3里的tick与价格表示
代码地址： https://github.com/Uniswap/v3-core/blob/main/contracts/UniswapV3Pool.sol
0G核心模块|AIVerse
ERC7857（iNFT）什么是 ERC7857/INFTERC-7857（也称 INFT）是一种面向 智能体/AI 代理的 NFT 标准，支持 可进化元数据、加密功能元数据以及功能性资产的安全转移，弥补传统 ERC-721 在 AI 场景中的不足。 NFT 不适配 AI 的原因1. Static Metadata（静态元数据） 传统 NFT（如 ERC-721）元数据固定，不支持自我学习或自我演化 无法随着 AI 代理能力或状态变化而更新 2. Insecure Metadata Transfer（元数据传输不安全） NFT 转移只涉及所有权转移 底层功能性元数据未随之安全转移 存在信息泄露或功能丢失风险 3. Publicly Accessible Metadata（元数据公开可访问） NFT 元数据默认公开 缺少原生加密机制 关键功能或敏感信息无法保护 REC7857的技术细节步骤 调用 transfer() 方法，开启转账流程。 合约向 Oracle 发起询问，询问目标 “newDataHash” 相关情况。 Oracle 回复接收方是否能访问...
V3中的集中流动性和流动性计算
集中流动性（Concentrated Liquidity）传统的 AMM 流动性是整个价格曲线连续分布的，而 V3 允许 LP（流动性提供者）把资金集中在某个 价格区间 [P_min, P_max] 内。 1. 背景在 Uniswap V2 中，流动性提供者（LP）是 全价区间流动性 模式： 流动性必须从 0 到 ∞ 的价格范围内均匀分布。 结果是，大部分资本几乎不会被用到（因为实际交易只发生在某个较小的价格区间）。 这导致资本利用率很低。 2. 集中流动性的核心思想集中流动性（Concentrated Liquidity）： 流动性提供者（LP）不再需要把资金放在整个价格区间，而是可以选择 某个价格区间 来提供流动性。 比如： 你可以只在 1000–2000 USDC/ETH 区间提供流动性。 如果 ETH 价格一直在 1500–1800 之间，你的资金就几乎全都在发挥作用。 3. 技术实现Uniswap V3 的做法是： 把价格区间离散化为一系列 ticks（刻度）。 LP 在提交流动性时，要指定一个区间 [tickLower, tickUpper]。 只有当当...