EOS 相关问题
石墨烯（graphene，读作gurafin，没有尾音 i）技术本身是由 cryptonomex 开发的一个库，目前已经有国内的开发者开始使用它来开发公有链相关的基础设施。BM-丹尼尔•拉里默（Dan Larimer）是 cryptonomex 的创始人。
EOS 声称自己具有以下几个优点：
- 不易分叉
- 高 TPS
- 可以平滑升级
EOS 的365天众筹模式可以让 EOS 团队负成本的操盘。EOS 总量是无限的，（据说）增发的部分只是给矿工创造价值。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2018-01-30
几种共识算法
达成共识的英文原文是 come to consensus。达成共识以后，也未必代表数据是完全一致的（Raft 算法中 leader 发出 append log 的 commit 命令即算达成共识？但如果中途数据丢失，则还是会有子节点数据不一致）。 在分布式环境下，多个系统协同工作的效率，受制于系统交叉点的性能。在需要达成分布式共识的场景下，分布式共识算法在保证系统安全性的同时，限制了全系统横向扩展的性能提升。 根据环境的不同，可以应用不同的共识算法。 在完全互信的环境下-私有链、私有的分布式数据库，节点之间可以使用 Paxos 或者 Raft 这种 leader 相对固定的算法。 在有限互信的环境下-联盟链，可以使用 PBFT。PBFT 算法是依据确定性的投票（可能是漫长的投票，也可能进入死循环）达到确定性一致的算法。 在没有互信的情况下-公有链，可以使用 POW/POS/DPOS/POA。这类算法是基于概率得到正确的最终一致性，性能比 PBFT 要稍微好点。 最好的共识算法应该模块化，例如 Corda 中的 notary，Hyperledger fabric 中的 solo/k...
2026-10-05
区块链（14）：PBFT 的法定集合为何需要换主证明
先修区块链（01）：两份签名都正确，账本仍会冲突的成员问题，以及旧文分布式系统（33）：PBFT、恶意节点与信任边界的认证副本。经典 PBFT 把服务限制在已知成员的确定性复制状态机中：n=3f+1，最多 f 个 Byzantine 副本；正确副本的密钥不泄露，网络可延迟与分区。任意两个大小 2f+1 的证书至少相交 f+1 个成员，交集中至少一个正确副本。这个算术只给同槽不双投提供基础，不是完整的换主安全证明。 flowchart LR C[客户端请求] --> P[primary: 分配 view 和序号] P --> PP[PRE-PREPARE] PP --> PR[PREPARE: 检查是否矛盾提议] PR --> CO[COMMIT: 传播锁定证据] CO --> EX[按序执行并回复] P -->|失联或作恶| VC[换主: 携带已准备证据] VC --> PP 恶意 primary 可对两个副本发不同请求摘要；副本通过准备阶段互核 (view, sequence, digest)，不能把普通多数...
2026-10-05
区块链（21）：ABI、数据位置与事件各承诺什么
后台拿到订单合约事件 Delivered(orderId) 就把业务表改成“最终交货”，至少跨过了两条未证明的边界：事件来自哪条规范历史，以及现实交货由谁证明。ABI 决定调用输入/输出如何从字节解释，合约 storage 决定持久状态，事件日志便于检索已执行路径；日志不是当前状态的唯一来源，也不会自己监督卖家。 先修区块链（20）：教学托管合约先写清谁能推动状态。调用动态数据时，ABI 编码需要指向尾部数据的偏移和长度；calldata 承载外部调用的输入字节，memory 是一次执行的临时区域，storage 承载持久键值。将 storage 引用传给辅助函数可能原地改状态，将其复制到 memory 则不是同一个持久对象；具体 gas、布局和类型尺寸依赖编译器/EVM 目标，不能凭概念图推出物理槽号。 flowchart LR C[calldata: selector + ABI 参数] --> E[函数与内部调用] E --> M[memory: 临时构造] E --> S[storage: 持久订单状态] E --> L[日志: t...
2026-10-05
区块链（32）：Optimistic rollup 的挑战窗口给谁留时间
把 L2 批次提交到底层链不代表批内每条交易在提交时都已由底层逐笔重算。Optimistic rollup 在规定前提下允许提出执行结果，并给有资格的挑战者机会提交反例或交互争议；最终用户退出依赖争议规则、可用数据、合约配置和挑战窗口。区块链（31）：通道、侧链与 rollup 把哪些责任移出主链的“结算位置”不能简化为“一发批次立即无条件终局”。 sequenceDiagram participant S as 排序器/批次提出者 participant L as 底层结算合约 participant C as 挑战方 participant U as 退出用户 S->>L: 提交批次状态主张与数据关系 L-->>C: 在挑战期检查主张 C->>L: 若错误，按协议提交争议证据 L-->>U: 解决后按退出规则领取 安全需要至少有能取得所需数据、能参与且愿意发起挑战的诚实观察者；活性还需排序器或替代包含/退出路径不会永久受阻。部分系统允许用户在 L2 被审查时向 L1 强制纳入，具体权限与等待期必须...
2026-10-05
区块链（05）：同一笔支付在 UTXO 与账户账本里的两种状态迁移
买家拥有面额为 100 的一份合成资产，要向卖家支付 70，手续费 1，剩余 29 归买家。UTXO 模型要解释“旧输出被消费，新输出怎样生成”；账户模型要解释“余额和 nonce 如何变化”。两种表示都要保证没有凭空产生价值，但拒绝重复支出的检查点不同。先修 区块链（01）：两份签名都正确，账本仍会冲突 的双签冲突，以及 区块链（03）：签名证明授权了哪条消息 的授权边界。 先固定不变量，再看两种状态 合成单位都是整数，不讨论小数位。模型假定输入已被正确授权，但没有验证签名、脚本、gas 或协议费用规则。对 UTXO，初始状态只有 ("synthetic-coin", 0) -> (buyer, 100)；交易引用该输出，生成 (seller, 70) 与 (buyer, 29)，旧输出从未花费集合删除，手续费为 100 - 70 - 29 = 1。找零是一个新的可花费输出，不是将原输出的余额改成 29。 flowchart LR U[未消费输出 buyer:100] -->|消费同一 outpoint| T[交易] T --> S...
2026-10-05
区块链（11）：重组时撤销的不是一个确认数字
一份订单支付曾在 A 分支入块，后台将它标为“可交付”；恢复连接后节点改选另一条有效分支，支付离开当前规范链。旧区块头与旧交易的历史存在没有消失，但按当前链计算的 UTXO 集合已改变。区块链（10）：交易池与 P2P 为什么不能当共识账本提到的传播差异只是起点：真正危险的是应用不撤回旧链衍生出的业务决策。 设共同祖先高度 h，A 后继块消费买家输入并支付卖家，B 后继块把同一输入付给攻击者。节点不能简单把两条分支的 UTXO 结果取并集；必须断开被替换区块，撤销旧输出产生与旧输入消费，再按新分支顺序接入块。若旧交易与新分支冲突，它无法自动重新纳入；若仍有效，可能重新进入池等待未来纳入。具体再接收与否还依赖节点政策。 flowchart LR H[共同祖先 h] --> A[分支 A: 卖家收款] --> A2[订单暂记已付] H --> B[分支 B: 冲突支出] --> B2[累计工作胜出] B2 --> U[撤销 A 的 UTXO 效果并应用 B] U --> X[索引与业务账本撤销/补偿] A2 -.不能只留旧状态....
