分布式详解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]。 只有当当...
V2中的闪电贷和TWAP
Flash Swap什么是闪电贷闪电贷 是一种 无需抵押的贷款机制,主要出现在 DeFi(去中心化金融)协议里。 它的核心特点是: 用户可以瞬间借到大量资金(几乎没有上限,只受池子流动性限制)。 必须在同一个交易(同一个区块内)还清。 如果没有还清,整个交易会直接被回滚(就像从没发生过一样)。 所以协议提供者不会有风险。 闪电贷有什么用? 套利 不同交易所(比如 Uniswap、SushiSwap、Curve)之间价格差异,瞬间搬运套利。 清算 在借贷协议(比如 Aave、Compound)里,当有人抵押物不足时,你可以用闪电贷借钱去清算,然后赚取奖励。 抵押物替换 假如你在 MakerDAO 抵押 ETH 借了 DAI,但想换成 WBTC 抵押,可以用闪电贷无缝替换,不需要先卖掉 ETH 再买 BTC。 高杠杆操作 利用瞬时借贷,把本金放大很多倍,进行投机或策略。 为什么 Uniswap V2 也能提供闪电贷? Uniswap V2 引入了一个机制:你可以拿走池子里的代币,只要在交易结束前归还相同数量的代币(或等值代币)。 这正好可以被用来实现 闪电贷...
V2中添加/移除流动性&无常损失
前置文章: https://kizzy899.github.io/2025/08/06/Uniswap%E4%B8%93%E9%A1%B9/ 项目代码: https://github.com/Uniswap/v2-core/blob/master/contracts/UniswapV2Pair.sol 添加流动性 在 Router.addLiquidity() 流程中: Router 会先调用 Factory.getPair(tokenA, tokenB) 检查池子是否存在 getPair[token0][token1] 用来查询该交易对是否已经存在 Pair 合约。 如果返回 非零地址,说明这个交易对已经有 Pair 了 → **不会再调用 create2**。 如果返回 零地址,才会用 create2 部署新的 Pair 合约,并初始化。 如果不存在 → Factory.createPair(tokenA, tokenB) 创建一个新的 Pair 合约 然后 Router 才把用户代币转到 Pair 并调用 mint() mint() : 把用户...










