Arbitrum 的 Nitro 项目 Rollup 细节深入

Arbitrum Nitro交易速度压力测试实战:TPS性能评估全解析 性能评估,其实本质上要做的工作是数据分析,我们只要清晰的定义数据,然后从数据中进行计算,就可以得到相应的指标 阅读详情

关于 rollup 向一层提交交易的我们上面文章已经由提到,此处主要主要剖析 rollup 合约,rollup watcher 和欺诈证明之间的交互和细节的逻辑整理。

一. validator 各子模块代码解析

  • block_challenge_backend 和 challenge_manager 区块挑战相关的代码
  • block_validator:区块验证逻辑,这里是衔接 arbnode 和 geth 的区块验证模块
  • rollup_watcher:rollup 合约交易事件的观察者

二. 2. Rollup 细节

汇总协议跟踪汇总块链——为了清楚起见,我们将这些称为“RBlocks”。它们与第 1 层以太坊区块不同,也与第 2 层 Nitro 区块不同。您可以将 RBlocks 视为形成一个单独的链,由 Arbitrum 汇总协议管理和监督。

关于汇总块链相关的解释请参考:nitro/inside-arbitrum-nitro.md at master · OffchainLabs/nitro

rollup_watcher 会去监听 rollup 相关的事件,监听的事件如下:

var rollupInitializedID common.Hash
var nodeCreatedID common.Hash
var challengeCreatedID common.Hash

这些事件分别由 LookupCreation LookupNode LookupNodeChildren 和 LookupChallengedNode 等方法处理,L1Validator 将这些调用这里面的方法获取相关的合约事件信息验证。

RollupNode 定义

 struct Node {
    // Hash of the state of the chain as of this node
    bytes32 stateHash;
    // Hash of the data that can be challenged
    bytes32 challengeHash;
    // Hash of the data that will be committed if this node is confirmed
    bytes32 confirmData;
    // Index of the node previous to this one
    uint64 prevNum;
    // Deadline at which this node can be confirmed
    uint64 deadlineBlock;
    // Deadline at which a child of this node can be confirmed
    uint64 noChildConfirmedBeforeBlock;
    // Number of stakers staked on this node. This includes real stakers and zombies
    uint64 stakerCount;
    // Number of stakers staked on a child node. This includes real stakers and zombies
    uint64 childStakerCount;
    // This value starts at zero and is set to a value when the first child is created. After that it is constant until the node is destroyed or the owner destroys pending nodes
    uint64 firstChildBlock;
    // The number of the latest child of this node to be created
    uint64 latestChildNumber;
    // The block number when this node was created
    uint64 createdAtBlock;
    // A hash of all the data needed to determine this node's validity, to protect against reorgs
    bytes32 nodeHash;
}

参加 rollup 的角色:分别由 WatchtowerStrategy,DefensiveStrategy, StakeLatestStrategy 和 MakeNodesStrategy
代码定义如下,该代码位于 staker.go 里面:

const (
   // Watchtower: don't do anything on L1, but log if there's a bad assertion
   WatchtowerStrategy StakerStrategy = iota
   // Defensive: stake if there's a bad assertion
   DefensiveStrategy
   // Stake latest: stay staked on the latest node, challenging bad assertions
   StakeLatestStrategy
   // Make nodes: continually create new nodes, challenging bad assertions
   MakeNodesStrategy
)
  • Staker start 任务启动之后,先会去更新认证区块的 wasm moudle root, 函数调用如下
err := s.updateBlockValidatorModuleRoot(ctx)

updateBlockValidatorModuleRoot 里面会去从 rollup 的中取到 WasmModuleRoot 更新到 blockValidator 里面, 当然 l1 validator 初始化的时候也会去更新相应的 WasmModuleRoot,并把 WasmModuleRoot 设置成 blockValidator 当前的 ModuleRoot,以供验证使用。

  • 获取到 callOpts 的信息,供下面的函数调用,该信息包含
type CallOpts struct {
   Pending     bool            // Whether to operate on the pending state or the last known one
   From        common.Address  // Optional the sender address, otherwise the first account is used
   BlockNumber *big.Int        // Optional the block number on which the call should be performed
   Context     context.Context // Network context to support cancellation and timeouts (nil = no timeout)
}
  • 清除构建的交易
func (b *ValidatorTxBuilder) ClearTransactions() {
   b.transactions = nil
}
  • 从 rollup 的 StakerMap 里面获取最新质押者的信息,包含挑战的信息
  • 从 validatorUtils 中拿到最新的质押数据信息,调用的合约函数如下:
function latestStaked(IRollupCore rollup, address staker)
    external
    view
    returns (uint64, Node memory)
{
    uint64 num = rollup.latestStakedNode(staker);
    if (num == 0) {
        num = rollup.latestConfirmed();
    }
    Node memory node = rollup.getNode(num);
    return (num, node);
}
  • 判断 Rblocks 是否分叉,validatorUtils.AreUnresolvedNodesLinear -> _ValidatorUtils.contract.Call(opts, &out, “areUnresolvedNodesLinear”, rollup)最终调用到这个合约函数进行判断
function areUnresolvedNodesLinear(IRollupCore rollup) external view returns (bool) {
    uint256 end = rollup.latestNodeCreated();
    for (uint64 i = rollup.firstUnresolvedNode(); i <= end; i++) {
        if (i > 0 && rollup.getNode(i).prevNum != i - 1) {
            return false;
        }
    }
    return true;
}
  • 如果发生了分叉,effectiveStrategy将由 DefensiveStrategy 切换成 StakeLatestStrategy,否则将按照 WatchtowerStrategy 往下执行
    代码如下:
nodesLinear, err := s.validatorUtils.AreUnresolvedNodesLinear(callOpts, s.rollupAddress)
if err != nil {
   return nil, err
}
if !nodesLinear {
   log.Warn("rollup assertion fork detected")
   if effectiveStrategy == DefensiveStrategy {
      effectiveStrategy = StakeLatestStrategy
   }
   s.inactiveLastCheckedNode = nil
}

s.bringActiveUntilNode 存储并且 info.LatestStakedNode < s.bringActiveUntilNode, effectiveStrategy 会由 DefensiveStrategy 切换到 StakeLatestStrategy

  • 获取 rollup 链最新确认的节点,调用栈 s.rollup.LatestConfirmed(callOpts)->latestConfirmed, 合约函数细节如下:
/// @return Index of the latest confirmed node
function latestConfirmed() public view override returns (uint64) {
    return _latestConfirmed;
}
  • 判断是否需要做质押提升, isRequiredStakeElevated获取CurrentRequiredStake, 和 baseStake 判定是否要做质押提升,(获取现在的 stake, 最终进入 currentRequiredStake 函数, baseStake 进入合约处理逻辑)
  • effectiveStrategy 为 MakeNodesStrategy 策略,或者 effectiveStrategy 为 StakeLatestStrategy 并且 rawInfo(staker 的信息为 nil) 并且需要提升质押的情况,会去处理以下这些逻辑
    • 处理超时的挑战 resolveTimedOutChallenges, 进入处理挑战的细节,下面的内容会说到
    • 处理 unresolve 节点, unresolve 处理逻辑:处理节点的类别有三种,代码如下:
const (
   CONFIRM_TYPE_NONE ConfirmType = iota
   CONFIRM_TYPE_VALID
   CONFIRM_TYPE_INVALID
)

处理逻辑是先去获取 confirmType 和 unresolvedNodeIndex,分别调用 ValidatorUtils 里面的 checkDecidableNextNode 函数和 rollup 的 firstUnresolvedNode,如果是 CONFIRM_TYPE_INVALID 类别的,直接拒绝下一个节点,如果是 CONFIRM_TYPE_VALID,查找并确认下一个节点。核心逻辑代码如下

func (v *L1Validator) resolveNextNode(ctx context.Context, info *StakerInfo, latestConfirmedNode *uint64) (bool, error) {
   callOpts := v.getCallOpts(ctx)
   confirmType, err := v.validatorUtils.CheckDecidableNextNode(callOpts, v.rollupAddress)
   if err != nil {
      return false, err
   }
   unresolvedNodeIndex, err := v.rollup.FirstUnresolvedNode(callOpts)
   if err != nil {
      return false, err
   }
   switch ConfirmType(confirmType) {
   case CONFIRM_TYPE_INVALID:
      addr := v.wallet.Address()
      if info == nil || addr == nil || info.LatestStakedNode <= unresolvedNodeIndex {
         // We aren't an example of someone staked on a competitor
         return false, nil
      }
      log.Info("rejecing node", "node", unresolvedNodeIndex)
      _, err = v.rollup.RejectNextNode(v.builder.Auth(ctx), *addr)
      return true, err
   case CONFIRM_TYPE_VALID:
      nodeInfo, err := v.rollup.LookupNode(ctx, unresolvedNodeIndex)
      if err != nil {
         return false, err
      }
      afterGs := nodeInfo.AfterState().GlobalState
      _, err = v.rollup.ConfirmNextNode(v.builder.Auth(ctx), afterGs.BlockHash, afterGs.SendRoot)
      if err != nil {
         return false, err
      }
      *latestConfirmedNode = unresolvedNodeIndex
      return true, nil
   default:
      return false, nil
   }
}
  • 若 stakeInfo 的不为 nil, 并且最新节点 stake 节点小于最新确认节点,effectiveStrategy 为 WatchtowerStrategy 和 DefensiveStrategy,退还当前在最新确认节点上或之前质押的质押者的质押币,从汇总链中提取发件人拥有的未承诺资金, 调用方法为 s.rollup.ReturnOldDeposit 和 s.rollup.WithdrawStakerFunds,最好执行交易 ExecuteTransactions
  • walletAddressOrZero != (common.Address{})条件下继续做自己取回处理
  • 接下来是解决冲突 handleConflict, 条件满足的情况下回去创建挑战,然后进入挑战细节
  • rawInfo != nil || !resolvingNode || !requiredStakeElevated, 提升质押,
    提升质押的细节逻辑
func (s *Staker) advanceStake(ctx context.Context, info *OurStakerInfo, effectiveStrategy StakerStrategy) error {
   active := effectiveStrategy >= StakeLatestStrategy
   action, wrongNodesExist, err := s.generateNodeAction(ctx, info, effectiveStrategy, s.config.MakeAssertionInterval)
   if err != nil {
      return err
   }
   if wrongNodesExist && effectiveStrategy == WatchtowerStrategy {
      log.Error("found incorrect assertion in watchtower mode")
   }
   if action == nil {
      info.CanProgress = false
      return nil
   }

   switch action := action.(type) {
   case createNodeAction:
      if wrongNodesExist && s.config.DisableChallenge {
         log.Error("refusing to challenge assertion as config disables challenges")
         info.CanProgress = false
         return nil
      }
      if !active {
         if wrongNodesExist && effectiveStrategy >= DefensiveStrategy {
            log.Warn("bringing defensive validator online because of incorrect assertion")
            s.bringActiveUntilNode = info.LatestStakedNode + 1
         }
         info.CanProgress = false
         return nil
      }

      // Details are already logged with more details in generateNodeAction
      info.CanProgress = false
      info.LatestStakedNode = 0
      info.LatestStakedNodeHash = action.hash

      // We'll return early if we already havea stake
      if info.StakeExists {
         _, err = s.rollup.StakeOnNewNode(s.builder.Auth(ctx), action.assertion.AsSolidityStruct(), action.hash, action.prevInboxMaxCount)
         return err
      }

      // If we have no stake yet, we'll put one down
      stakeAmount, err := s.rollup.CurrentRequiredStake(s.getCallOpts(ctx))
      if err != nil {
         return err
      }
      _, err = s.rollup.NewStakeOnNewNode(
         s.builder.AuthWithAmount(ctx, stakeAmount),
         action.assertion.AsSolidityStruct(),
         action.hash,
         action.prevInboxMaxCount,
      )
      if err != nil {
         return err
      }
      info.StakeExists = true
      return nil
   case existingNodeAction:
      info.LatestStakedNode = action.number
      info.LatestStakedNodeHash = action.hash
      if !active {
         if wrongNodesExist && effectiveStrategy >= DefensiveStrategy {
            log.Warn("bringing defensive validator online because of incorrect assertion")
            s.bringActiveUntilNode = action.number
            info.CanProgress = false
         } else {
            s.inactiveLastCheckedNode = &nodeAndHash{
               id:   action.number,
               hash: action.hash,
            }
         }
         return nil
      }
      log.Info("staking on existing node", "node", action.number)
      // We'll return early if we already havea stake
      if info.StakeExists {
         _, err = s.rollup.StakeOnExistingNode(s.builder.Auth(ctx), action.number, action.hash)
         return err
      }

      // If we have no stake yet, we'll put one down
      stakeAmount, err := s.rollup.CurrentRequiredStake(s.getCallOpts(ctx))
      if err != nil {
         return err
      }
      _, err = s.rollup.NewStakeOnExistingNode(
         s.builder.AuthWithAmount(ctx, stakeAmount),
         action.number,
         action.hash,
      )
      if err != nil {
         return err
      }
      info.StakeExists = true
      return nil
   default:
      panic("invalid action type")
   }
}

接下来的流程:createConflict->BuildingTransactionCount->ExecuteTransactions

完整layer2 github 链接:https://github.com/guoshijiang/layer2

Arbitrum自建RPC节点 Arbitrum自建RPC节点 全节点 arbitrum节点 arbitrum 阅读详情

相关推荐

Arbitrum Nitro 技术栈解析:从 Geth 核心到 WASM 证明的 3 层架构演进

本文深入解析了Arbitrum Nitro技术栈的三层架构设计,从Geth核心到WASM证明的演进过程。通过复用Geth代码实现高效执行,结合ArbOS中间件和WASM证明机制,Nitro在Optimistic Rollup赛道中展现出卓越的性能与安全性。文章详细探讨了架构设计、技术实现及性能优化策略,为开发者提供全面的技术参考。

weixin_42552410的博客 255

Arbitrum 的 Nitro 项目启动和交易执行源码解析

Arbitrum 的 Nitro 项目启动和交易执行源码解析

Hacker的博客 1523

为什么说第二代Optimistic Rollup是Layer2的未来?

为什么说第二代Optimistic Rollup是Layer2的未来?

qq_32193015的博客 614

区块链--Arbitrum Rollup(Layer2)

Arbitrum是OffchainLabs 团队开发的以太坊Layer2层扩容方案,可以实现高吞吐量,让开发者以低成本部署、运营智能合约,同时可以保持无需信任的安全性 总结:Rollup的主要特点是所有交易数据都记录在链上,也就是说,Arbitrum把关乎安全的部分放在以太坊链上,将实际计算和存储放在链下执行。...

知识的共享,拓宽视野,深化思考,获得新的启发. 6090

用AI构建加密技术决策框架:从需求到落地的工程化路径

加密技术不是抽象数学,而是解决真实业务约束的工程工具。理解其核心在于掌握信任模型、性能边界与合规适配三重维度——零知识证明(ZKP)让验证者不接触原始数据即可确认真实性,同态加密(FHE)支持密文直接计算,二者共同拓展了隐私保护型系统的设计空间。这类密码学原语的价值,不在于理论先进性,而在于能否在吞吐量、延迟、硬件成本和法律效力等硬指标下稳定交付。典型应用场景包括跨境供应链存证、医疗数据共享验证、物联网设备轻量认证等对数据主权与可验证性双重要求的领域。本文聚焦如何以AI为认知透镜,将模糊业务需求转化为可量化

weixin_30908103的博客 411

2026代币价值校准器:基于链上数据的动态评估方法论

区块链代币价值评估正从主观叙事转向可验证的链上实证体系。其核心原理在于将‘划算’定义为多变量约束下的动态优化问题,涵盖收益预期、流动性质量、持有成本与治理时效四大维度。技术价值体现在对Gas费波动、跨链安全冗余、开发者留存率等真实链上指标的量化建模;典型应用场景包括早期资产配置、机构级尽调及DeFi持仓健康度诊断。本文聚焦2026这一关键时间锚点,深度融合链上经济健康度(OCEH)与开发者活性可信度(DAC)两大热词,提供一套无需Solidity基础、仅依赖Dune、Etherscan和基础数学即可落地的自

weixin_30335353的博客 539

Arbitrum白皮书疑点问题整理解析(记录)

不,可以通过在Aribitrum上的流动性提供商进行提款(可能需要更高额的手续费),即将钱转给一个第三方,第三方在主网上把钱转给你,但是要当心黑心第三方卷款跑路哦。

weixin_43380357的博客 704

declarative-lookup-rollup-summaries:查找的声明性汇总摘要

查找字段关系的声明性汇总 功能摘要 如果不编写Apex触发器,以前无法在Lookup关系之间建立汇总信息 声明式地使用标准UI定义汇总,无需编码 定义汇总汇总的过滤条件,例如,“机会汇总汇总”到“已关闭赢取的帐户”上 支持实时,预定和开发人员API模式 开源,提供代码和托管程序包形式。 托管软件包已通过Salesforce安全审查,并且已启用Aloha 支持自定义元数据,汇总可以包含在变更集和软件包中,以便于部署 请参阅下面的博客文章以获取更多详细信息。 社区支持 这是一个社区驱动的工具,请提供支持,并在此分享您的经验。 文献资料 除了之外,随着它的发展,该工具还出现在许多博客条目中。 注意:链接按时间顺序排列,如果您是第一次使用该工具,请从下往上阅读 汇总和跨对象公式字段 包装和安装汇总 声明式查找汇总摘要工具和自定义元数据 声明性汇总汇总-Spring'15版本 用于Force.

Arbitrum 之 深入了解 Arbitrum Orbit

Arbitrum Orbit 是一个模块化的 Layer 3 技术栈,旨在让开发者部署自己的区块链——称为“Orbit 链”。这些链将交易结算到 Arbitrum 的 L2 网络(如 Arbitrum One 或 Arbitrum Nova),而 L2 网络再将交易结算到以太坊的 Layer 1(L1)。Orbit 链可以配置为 Rollup 或 AnyTrust 链,在安全性、成本和性能之间提供灵活的平衡。

web3 1398

算法-基于MACD的Adaboost股价涨跌预测模型

MACD是一个指标,具体用法是MACD>0看涨,反之看跌,果真是这样的吗?由于所有的技术指标都基于对历史数据的统计,指标的滞后性也就难免,有时候MACD明明大于0,股价仍然跌,有时候macd小于0,股价仍然涨。 本文基于Adaboost算法提出了一种基于macd的线性阀值分类器作为若分类器,通过在限定的解空间内寻找使得错误率最小的阀值和偏置,这样做避免了训练若分类器的复杂性,经验证,这种方法有效。

mtaxot的博客 8023

WRF实战:自定义Vtable解析ECMWF海温数据的关键步骤与技巧

本文详细介绍了在WRF模型中自定义Vtable以解析ECMWF海温数据的关键步骤与技巧。通过解剖GRIB文件、编写自定义Vtable条目以及配置METGRID.TBL,解决了ECMWF数据与WRF模型对接的难题,为海洋气象和台风模拟研究提供了高精度数据输入方案。

weixin_29279101的博客 338

L2 元年,Arbitrum Nitro 升级带来更兼容高效的开发体验

Arbitrum 作为基于以太坊 L2 扩展解决方案,自去年8月底上线以来,凭借低成本和高速度的用户体验,同时保持去信任化的安全优势,又与 EVM 完全兼容,迅速获得了广大用户和开发者的青睐。

TinTinCommunity的博客 1078

HyperLPR3车牌识别-Android-SDK光速部署与使用

基于深度学习高性能中文车牌识别 High Performance Chinese License Plate Recognition Framework.快速部署AndroidSDK

tunm 6121

Arbitrum 专访 | L2 Summer, 脱颖而出的 Arbitrum 为开发者带来了什么?

Jerry你好,我是Jerry,现在Arbitrum主要担任中文区的市场和内容策划,是今年五月加入团队的。我一开始主要是对Web3和去中心化的理念有着浓厚的兴趣,并且对社区生态与内容产出本身有着一些经验,又非常喜欢玩NFT,所以很高兴能够加入到Arbitrum当中,与大家一起迈入扩容以太坊的征途。Jason你好,我是Jason,是Arbitrum的集成工程师。JerryArbitrum拥有Layer2最大,最为活跃的中文社区,我们一直非常重视它的成长与未来规划。翻译计划。...

TinTinCommunity的博客 996

Jetpack Compose Navigation实战:从基础到高级导航模式

本文全面解析Jetpack Compose Navigation在Android开发中的应用,从基础导航实现到高级模式(如单任务/单顶模式),涵盖参数传递、嵌套导航、深层链接等核心功能。通过实战代码示例展示如何优化导航性能,并与ViewModel、Hilt等架构组件整合,为开发者提供高效的Compose导航解决方案。

pz890123456的博客 374

【数据挖掘】遗传算法原理浅析:什么是遗传算法?遗传算法的工作原理是什么?

遗传算法(Genetic Algorithm,GA),是进化算法的框架和核心。 各种进化算法有什么异同? - 及时物语的回答 - 知乎 https://www.zhihu.com/question/39152390/answer/901070749

纸羊同学的博客 4280

Arbitrum Classic与Nitro技术栈对比分析:经典版与现代版的差异

Arbitrum Classic是旧版"经典"Arbitrum技术栈,而Arbitrum One已于2022年8月升级为使用Nitro技术。本文将深入对比这两个版本的核心差异,帮助开发者理解从经典版到现代版的技术演进。 ## 📌 技术架构对比 ### Arbitrum Classic架构 Arbitrum Classic采用原始的Arbitrum技术架构,其核心组件包括: - 基于AVM(

gitblog_00430的博客 347

Lattice CrosslinkNx LIFCL-40实战解析:MIPI D-PHY硬核IP配置与CSI-2数据解析全流程

本文详细解析了Lattice CrosslinkNx LIFCL-40 FPGA中MIPI D-PHY硬核IP的配置与CSI-2数据解析全流程。通过实战案例,介绍了硬件环境搭建、寄存器配置、数据包结构解析及视频流重构技巧,帮助开发者快速掌握高速图像采集系统的设计与优化方法。

weixin_29159613的博客 200

Scroll vs Optimism vs Arbitrum:主流L2扩容方案终极对比

面对以太坊高昂的 Gas 费和拥堵,**L2 扩容方案**成为区块链世界最热门的话题。在众多方案中,**Scroll、Optimism、Arbitrum** 三大主流 Rollup 占据了绝对主导地位。本文将从技术路线、安全模型、交易费用、生态现状四个维度,为你做一次通俗易懂的 **L2 扩容方案对比**,帮你找到最适合自己的 Layer2。 ## 为什么我们需要 L2 扩容方案?🚀 以太坊

gitblog_00161的博客 331

Hierarchical Flow Partition(Top-down&&Bottom-up)

hierarchy flow是将设计切分成多个block,分别处理单个block,然后完成后,将它们进行拼接以完成最终的chip。一般划分为三个阶段:chip planning;physical budget就是pin assignmenthierarchy flow实现的方法有两种,一种是top-down,另一种是bottom-up,无论是哪种,都是都要通过flatten的方法分别全局范围进行优化实现。

qq_39493558的博客 3072

从 AI 助手到 ADT 自动化桥梁:全面解析 Vibing Steampunk 的定位、能力边界与典型使用场合

Vibing Steampunk是一个面向SAP ABAP开发的AI自动化工具集,它通过ADT API将SAP开发能力系统化地暴露给AI助手和命令行工作流。该工具支持ECC、S/4HANA等所有启用ADT的系统,提供代码读取、修改、测试、调试等全流程自动化能力。核心功能包括AI调试、上下文压缩、ABAP语言服务、Lua脚本自动化等,并内置多重安全控制。其分层架构兼容标准ADT和WebSocket扩展,既适合AI驱动开发,也支持传统DevOps自动化,特别适用于老系统代码考古、知识接力和复杂问题诊断场景。

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 152

Arbitrum Classic测试网络实战:从开发到部署的全流程演示

Arbitrum Classic是一套以太坊扩容解决方案,支持高吞吐量、低成本的智能合约,同时保持无需信任的安全性。本指南将带您完成从环境搭建到智能合约部署的完整流程,帮助您快速上手Arbitrum测试网络开发。 ## Arbitrum测试网络概览 📊 Arbitrum提供多个公共测试网络,适合不同开发阶段的需求: - **RinkArby**:长期运行的测试网,链ID 421611,使用

gitblog_01080的博客 287

温度PID控制PLC程序

温度PID稳定控制程序,适用于欧姆龙PLC,对其他PLC也具有很大参考价值

扩容领跑者 Arbitrum 抢占 Layer3 竞争高地

XAI 实现更高性能,Stylus 支持部署 Wasm 合约

TinTinCommunity的博客 830

最新的sdio 4.0 spec 协议标准 带书签 高清完整PDF版

Part-E1-SDIO-Specification-Ver4.00-Final-120220.pdf:最新的sdio 4.0 spec 协议标准 带书签 高清完整PDF版,包括SDIO 接口的外设,SDIO 接口官方协议等。

IMSL CNL 7.0.0 (x86-64)Crack

IMSL CNL 7.0.0 (x86-64)Crack intel的算法库破解文件,这是C++版本的破解文件

盘点八大 Layer 2 项目最新动态

以太坊合并后,Layer2 生态板块发展迅速。L2 在三季度TVL 增加了 97.1%,除此之外,Layer2生态项目也取得很多进展,本文将Layer2重点项目进行盘点,并梳理其最新动态。

qq_32193015的博客 1251

pscad IEEE标准系统搭建说明

pscad IEEE标准系统搭建说明,包含典型的IEEE 9节点、14节点、30节点、39节点和118节点系统。内含标准测试系统的原始数据和潮流结果。

走进 AnyTrust 技术底层,数据可用性和最小信任假设如何实现

这是因为,如果 N-1 名委员会成员需要承诺提供对某些数据的访问,承诺方只需要有一名诚实成员即可,同时为了避免该诚实成员在 N-1 之外,因此,总共需要至少 2 名成员为诚实节点。如果定序器未能在几分钟内收集到足够的签名,它将放弃使用委员会的尝试,并将通过将完整数据直接发布到 L1 链来“回退到 Rollup ”,就像在非 AnyTrust 链中所做的那样。每个委员会成员都将数据存储在其后备存储中,并按数据的哈希值编制索引。,则 L2 代码将读取数据块,该数据块保证可用,因为 DACert 有效。...

TinTinCommunity的博客 441

链上应用Token消耗成本建模与优化实战指南

在Web3基础设施演进中,代币已从增长燃料退化为刚性运营成本。理解Token消耗的本质,需回归其作为链上资源支付凭证的技术原理:它覆盖共识、执行、网络、数据与交互五层物理开销,并受Gas机制、RPC定价、存储租金等底层规则约束。其技术价值在于实现去中心化服务的可信调度与资源分配,广泛应用于DeFi协议、NFT平台、跨链索引服务及钱包SDK等场景。然而当前高波动Gas价格、低效RPC调用与隐性影子负债正导致补贴失效——真实案例显示,超90%的Token支出属于可优化的弹性消耗。本文聚焦工程可落地的成本计量、归

weixin_30274627的博客 319
上一篇: Arbitrum 的 Nitro 项目启动和交易执行源码解析
下一篇: The Web3 社区 Web3 产品经理课程
The_Web3_社区
博客等级 码龄10年 388粉丝 154原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

The_Web3_社区

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值