News.EOS.WiKi Bilingual News & Info Of EOS

Mandel v3.1版本功能/Mandel v3.1 Release Features

M
版本功能

译文/Translated:

Mandel v3.1版本区块链软件将数月的研究和开发浓缩为一次网络升级,其中包含了大量实用的功能和修复。

之前发布的蓝皮书概述了其中的一些功能。API+蓝皮书推荐了一些改进措施,以减少交易损失,提高交易生命周期的可预测性。

之前的文章探讨了主观计费系统如何导致交易丢失,并概述了针对常见交易生命周期问题(如交易丢失)的现有修复方法。 Mandel v3.1 版本引入了新工具来解决这些问题和其他用户体验障碍。

Mandel v3.1 版本引入了以下新的交易生命周期工具:
其他不以交易生命周期为重点的Mandel升级包括:
Mandel删除了: 
  • 历史插件,该插件在1.2版本中已被弃用 
  • MongoDB插件
  • 旧的构建脚本
  • Reversible区块数据库
  • 支持macOS和其他Linux发行版。Mandel v3.1版本只正式支持Ubuntu 18.04、20.04和22.04
  • 弃用了abi_bin_to_json和abi_json_to_bin的转换API

与EOSIO 1.8一样,Mandel v3.1版本需要协调协议的激活。节点必须更新二进制文件并改变配置设置,运行EOSIO 2.1的节点必须在区块生产者激活新的协议功能之前,采取一些其他的升级步骤。运营商需要在2022年9月21日的计划升级日期前,完成这些步骤。任何没有激活Mandel v3.1版本的节点,都无法在9月21日之后与网络的其他部分保持同步。

您可以在我们的升级指南中,找到有关升级步骤的更多详细信息。

新的Mandel v3.1版本功能

交易失败追踪和新交易端点

(详情细节)

Mandel v3.1版本引入了一个新的交易端点,当交易失败时,它包括一个详细的失败报告,并嵌入了交易异常。这个详细的报告就是交易失败追踪。不要把这个报告误认为是成功的交易追踪。您可能需要验证收据及其他字段,以确保交易成功。

在 Mandel v3.1 发布之前,交易失败会导致交易失败追踪,但没有失败的详细信息。Mandel v3.1的交易失败追踪指明了交易中失败发生的位置,并确定了是哪个操作导致了失败。新的 Mandel v3.1 交易端点默认启用此功能。

交易重试

(详情细节)

交易重试功能允许API 节点重新提交丢失的交易,直到它们被写入区块或过期。

存在一个背景知识,当用户连接到API 节点并向网络发送交易时,并不能保证该交易会成功进入区块。

存在许多问题,如主观计费或地理延迟,可以阻止交易在网络上传播到活跃的区块生产者。解决这些问题的方法之一是允许API 节点跟踪交易并纳入区块链,并重试区块生产者未在区块中发布的交易。

交易重试功能创建了一个传入交易池,并将交易暂时保留在池中。在被纳入一个区块后,该交易在池中保持一定数量的区块或直到该区块达到不可逆转状态。

节点运营商单独设置交易池参数和定义缺失交易的标准。 如果该工具根据这些标准检测到丢失的交易,它会重新将交易提交到网络。

交易终结状态

(详情细节)

交易终结状态功能允许节点分享给定交易的最终状态。它还会返回当前链状态的快照。

开发人员在其智能合约中实现的最常见功能之一是检查交易的最终状态。 使用当前工具,每个开发人员都必须构建自定义解决方案。 构建和重建交易最终状态的需求增加了开发时间,并增加了智能合约的利用的错误率。 允许节点直接提供交易的确定性信息具有很大的价值。

交易终结状态功能允许节点共享当前链状态的快照。启用该功能的节点可以存储交易状态并打开一个新的端点来查询该状态。如果交易没有出现在链上,它返回的状态是 「UNKNOWN」。

交易资源成本估算

(详情细节)

交易资源成本估算功能允许节点打开一个只读端点,该端点返回资源成本的估算值。

在 EOSIO 链中,活跃的区块生产者在执行时确定交易的成本。 区块生产者通过测量用于执行交易的非签名部分的CPU时间来确定CPU成本。区块生产者CPU性能的差异,使得在发送交易之前很难确定实际的资源成本。

交易资源成本估算功能可帮助用户和应用程序更准确地估算交易的资源成本。 资源成本估算功能会创建一个 API 端点,来接收未签名的交易。启用该功能的节点会根据API节点处理交易所需的时间,返回对交易资源成本的估计。

主观计费改进

(详情细节)

Mandel v3.1 版本的主观计费改进包括对两个现有工具的更改。 第一个更改允许节点从默认的 24 小时调整主观计费衰减时间。 第二个更改允许 API 节点使用区块生产者使用的三击规则(three-strikes rule),并允许调整三击(three-strikes rule)参数。

因为 EOSIO 链仅在区块生产者向区块链发布交易时才向账户收费,因此失败的交易实际上是免费的,有时会导致滥用。 三击规则(three-strikes rule)和主观计费工具减少了节点上的失败交易负载,但也带来了用户体验障碍。 Mandel 引入了可调节的主观计费和三击(three-strikes rule)参数来减轻用户体验障碍。

账户最大失败次数:

在主观计费之前,EOSIO 2.0.9 对区块生产者节点实施了三击规则(three-strikes rule)。 当账户在一个区块中发送了三个失败的交易时,三击(three-strikes rule)功能会放弃该账户的其余排队交易,从而减少失败交易的负担。

API节点现在可以在Mandel v3.1版本中使用这个功能。以前硬编码的3次限制现在也可以配置为任意数量的失败次数。

此外,已使用disable-subjective-account-billing 选项列入白名单的账户,将不再受到最大交易失败限制。

主观账户衰减:

节点通过使用主观计费来跟踪账户的每个节点的失败交易 CPU 预算,来防止过多的失败交易。 该协议在称为主观账户衰减的时期内将此预算返回给账户。 以前硬编码的 24 小时衰减时间现在变成可配置的。

对于当前的 24 小时时间窗口,对于 6 小时内未推送交易的账户,节点应用 6/24 或 ¼ 的乘法运算,只提供该账户原本可用资源的25%。

当时间窗口调整为 6 小时时,节点应用 6/6 ,即乘以 1 的乘法运算,这为同一账户提供了 100% 的可用资源。

当窗口设置为一小时时,测试发现一小时窗口可以有效地缓解失败的交易垃圾邮件,而不会出现用户体验问题。

其他功能:

其他新功能包括与加密相关的改进、新协议选项、修剪功能和日志记录改进。 一些功能优化了与 EVM 相关的注意事项,其余则为网络参与者要求使用来提高其工作流程效率的功能。

CRYPTO_PRIMITIVES 是一项引入七个新主机函数的功能。 主机函数比智能合约更快,因为它们是在本机代码中实现的,而不是在抽象的智能合约层中实现的。 这些函数可以更有效地计算许多基于 Solidity 和 EVM 的合约库中使用的加密函数。 新功能包括:

  • 一种更有效地执行模块指数化计算的算法( c=modm(bx)),这是哈希算法的一个有用公式。
  • alt_bn128 椭圆曲线上的三个函数:
    • 点数加法
    • 标量乘法
    • 双线性函数
  • 两个新的哈希函数:
    • sha3
    • blake2_f

这两个函数在零知识证明和其他保护隐私的数据验证方法中被广泛使用。

  • 升级了libsecp256k库,将k1密钥恢复能力提高了33%

Mandel v3.1 版本添加了 nodeos 节点选项来修剪块日志和状态历史插件。 当节点修剪这些文件时,它会从本地节点存储中删除旧数据来提高性能。

它还引入了在特定区块终止的选项,这对链状态快照很有用。

此外,它还包括用户对交易日志的定义字段,该协议称为GELF。该协议允许交易日志使用通用的语法进行共享,运营商可以很容易地与其他交易日志解决方案集成。

作为智能合约开发者的附加功能,Mandel 允许合约直接获取当前区块号。

本次升级还包含并改进了 EOSIO v2.1 版本中包含的多项功能,其中包括可配置的 WASM 限制和其他区块链参数。 它还添加了 EOSIO v2.1 版本中的 get_code_hash 和 action_return_value 内在函数。

Mandel v3.0 版本的更新

(详情细节)

Mandel v3.0 版本包括 EOSIO v2.1 版本中的几个功能,以及新功能和对测试、日志和格式的各种更改。 这些功能主要是为了使 Mandel 功能与 EOSIO v2.1 版本中的功能保持同步,同时省略那些网络不需要的EOSIO v2.1功能。 在 Mandel v3.1 版本中增加了其他功能,以提高效率并促进各种升级。

  • GET_CODE_HASH
  • ACTION_RETURN_VALUE
  • CONFIGURABLE_WASM_LIMITS2
  • BLOCKCHAIN_PARAMETERS

系统合约

(详情细节)

Mandel v3.1 版本更新了核心系统合约,并引入了新的启动合约以简化测试。 系统合约升级不需要协调一致的升级。

启动合约是一个新的系统合约,有助于启动一个新的区块链。它解决了一系列阻止运营商初始化一个新链的循环依赖关系。核心系统合约需要特定的协议功能,而在启动合约之前,这些功能需要核心系统合约来激活。启动合约规避了这个问题。它提供了另一种方法来激活特定的协议功能,它提供了另一种方法来激活核心系统合约所必需且没有依赖关系的特定协议功能。当在一个新的链上激活这个启动合约时,它允许激活核心系统合约,然后激活各个协议功能。

此外,核心系统合约现在还允许:

  • 可配置的 WASM 限制
  • setabi 和 setcode 中的备注字段
  • 限制权限更改的能力
  • 跟踪最近 10 个块的块信息表
  • 可调整区块链参数的更新
  • 各种bug修复和补丁。

合约开发工具包 (CDT)

(详情细节)

合约开发工具包 (CDT) 升级是一套工具,智能合约开发人员可以使用它来将他们的合约翻译成 Mandel 的原生代码库 WebAssembly。 CDT 3.0.0 版对该工具进行了几处更改。

开发人员需要注意的是,这个版本将工具包的名称从 “eosio.cdt” 改为 “cdt”。开发者需要修改他们的CMake文件,将 “eosio.cdt”的每个instance替换为 “cdt”,以适应这一变化。

CDT 为加密原语添加了 C++ 包装器,以允许合约使用这些原语。 当前发布的包装器是针对 SHA3 算法和当前块号的,但稍后会添加其他 C++ 包装器。

CDT还包括新的Stack Canary功能,防止堆栈溢出。

安装

Mandel v3.1 版本对核心软件的安装过程进行了更改。 与之前发布的更新相比,它还存在一些兼容性差异。

新的构建过程使用由 CMake 驱动的构建过程,而不是自定义 shell 脚本。 如果没有这些构建脚本,从源代码构建需要安装必要的依赖项。  readme文件中列出了这些依赖项和推荐的构建过程。

Mandel v3.1版本主要是为Ubuntu 20.04和22.04构建的,并支持Ubuntu 18.04,同时其他发行版、编译器和平台也可以使用。

由之前的版本进行升级

使用快照升级节点:

  1. 首先,从兼容的早期节点版本生成状态快照,比如 EOSIO v2.0 版本的节点版本。
  2. 删除节点的状态文件。
  3. 如果节点使用 EOSIO v2.1 版本,运营商还必须删除 SHiP 和区块日志。 运行 EOSIO v2.0 版本的节点不需要执行此步骤。
  4. 使用快照启动节点。
  5. 像之前一样启动和停止节点。

有关面对更复杂情况的更多详细信息或建议,请参阅我们发布的升级指南或联系EOS Support来获得帮助。

兼容性

(详情细节)

一般来说,Mandel v3.1版本与EOSIO v2.0版本的网络、快照、区块日志和状态历史插件(SHiP)日志兼容,但与EOSIO v2.1版本不兼容。

Mandel v3.1版本与早期软件版本的状态文件不兼容

用于节点执行的 Docker 实用程序 (DUNE)

DUNE 是一个设计用于在 macOS、Windows 10 和 11 ,以及 Mandel v3.1 版本不直接支持的其他操作系统上运行的环境。 DUNE 需要 Docker 和 Python3,但实施起来很简单,readme文件中包含每个操作系统的说明。 它提供与节点、cleos、cdt 和其他 Mandel v3.1 组件相同的命令。它还提供了涉及所有这些组件的其他抽象化命令。重要的是,它允许任何拥有Docker功能机器的开发者在EOS网络上开发和测试。

Mandel v3.1版本弃用和删除的内容

(详情细节)

Mandel v3.1 版本弃用了 ABI 转换 API ,并删除了几个弃用的功能。

ABI 转换 API 已弃用。

abi_bin_to_json 和 abi_json_to_bin 转换 API ,可将序列化数据与反序列化数据互相转换。 从 Mandel v3.1 版本开始,它们都已被弃用。

并删除了几个功能:

  • 老构建脚本

Mandel v3.1版本删除了安装节点、cleos、keosd及其依赖项的构建脚本。新的CMAKE脚本只安装节点、cleos和keosd,操作者必须先安装依赖项。

  • 历史插件

EOSIO v1.0 版本包含一个历史插件,但 EOSIO v1.2 在 2018 年 8 月 14 日弃用了这个历史插件,以支持更高性能的解决方案。 它将在 Mandel v3.1 版本中删除,使用 --plugin eosio::history_plugin 的节点应迁移到 --plugin eosio::trace_api_plugin 或 --plugin eosio::state_history_plugin

  • MongoDB插件

EOSIO v1.8 版本弃用了 MongoDB 插件,该插件允许节点将区块链数据存档到 MongoDB 数据库中。 Mandel v3.1 版本完全删除了这个插件。 节点操作者可以使用 state_history_plugin 等历史工具。

  • Reversible 区块数据库

Mandel v3.1 版本删除了Reversible区块数据库,并将Reversible区块存储在 fork 数据库中。 操作者应从 config.ini 文件和所有脚本中删除Reversible区块数据库的现有配置设置。

取消了对 Ubuntu 16.04、Centos 和 MacOS 的支持

Mandel v3.1版本取消了对MacOS、Ubuntu v16.04和CentOS Linux发行版的支持,以优化开发者资源。现在支持的平台是Ubuntu 18.04(有限支持)、20.04和22.04。对于使用这些不支持的操作系统的用户,DUNE提供了与任意Docker兼容的操作系统的兼容性。

总结

Mandel v3.1版本包括强大的工具和选项,用于改善EOS和其他基于EOSIO的区块链的功能和用户体验。作为协议升级,随着2022年9月21日预期激活日期的临近,它需要节点运营商之间协调一致。在此日期之后,区块生产者将更新其软件,钱包和应用程序可以开始集成Mandel v3.1版本的功能。随着这一网络升级的完成,EOS网络将迈出自主网络开发的第一步,使EOS这一区块链业务中的最佳技术更加出色。

详细发布说明

新的交易端点

新的chain_api_plugin端点功能包含了 transaction_retry 以及其他用于未来功能的参数。该端点是:

/v1/chain/send_transaction2 (send_transaction_params)

它类似于 send_transaction 端点,但具有其他选项。它有返回失败跟踪的选项和重试交易的选项。它具有与 send_transaction 相同的格式,但有新的配置参数(请参见A-1)。

交易重试

交易重试功能带有用于节点的新配置参数和cleos接口的新命令行选项。

配置参数用于调整节点的行为,可以在 config.ini 配置文件中使用,也可以直接在节点中使用。配置文件的配置项格式应为““option = value”,而命令行项格式可为“--option=value”或“--option value”。节点操作者可以在config.ini文件中或在启动节点实例时使用新的交易重试参数,包括:

transaction-retry-max-storage-size-gb

此选项设置了交易重试功能所允许的最大存储空间分配(单位:GiB)。将此数字设置为 0 以上会启用此功能。 禁用该功能的节点将拒绝对其请求交易。

transaction-retry-interval-sec (默认值为20)

此选项设置节点在未检测到区块中的交易时,应重新向P2P网络发送交易的频率(单位:秒)。

transaction-retry-max-expiration-sec (默认值为90)

此选项为重试池中的交易,设置允许的最长交易过期时间。如果交易的过期时间超过这个值,交易重试工具将不会把交易加入池中。

p2p-dedup-cache-expire-time-sec (默认值为10)

此选项设置重复数据删除缓存。 调整这个数字可以调整跟踪一个交易的最长时间(单位:秒),同时从交易池中删除它的重复部分。

 用户通过 cleos 与区块链交互的新命令行选项包括:

--use-old-send-rpc (T/F)

此选项强制 cleos 使用旧的交易格式,使用 send_transaction 而不是 send_transaction2 及其新功能。 它对于测试和调试旧 API 非常有效。

-t--return-failure-trace (T/F)

此选项向用户返回失败的交易信息。 它改进了调试,允许用户查看哪个特定操作失败了。

--retry-irreversible (T/F)

此选项允许交易签名者请求节点重试交易,直到它处于不可逆转的区块中或交易过期为止。 这是一个blocking call。如果节点没有启用该功能,它将返回一个错误。

--retry-num-blocks (T/F)

此选项允许交易签名者要求节点重试一个交易,直到该交易在规定数量的已生产区块中被看到,或者直到交易过期。这是一个blocking call。如果节点没有启用该功能,它将返回一个错误。

交易终结状态

交易终结状态功能返回交易状态以响应请求。 该工具将节点传播的交易存储在交易池中,直到交易过期或完成指定数量的区块。

它包括以下参数:

transaction-finality-status-max-storage-size-gb 

此选项设置交易终结状态池的存储大小(单位: GiB )。 当池大小达到此限制时,节点将放弃旧的交易。 将其设置为高于零会启用此功能。 禁用该功能的节点将拒绝向其请求交易。

transaction-finality-status-success-duration-sec

此选项定义了在一个成功的交易达到终结状态后,将被保留在交易终结状态池中的时间长度(单位:秒)。

transaction-finality-status-failure-duration-sec

T此选项定义了在一个失败的交易达到其到期时间后,将被保留在交易终结状态池中的时间长度(单位:秒)。

Cleos的新命令行选项

get transaction-status <id>

此选项允许节点在给定交易 ID 的情况下,返回当前的区块链状态和交易ID的信息,包括其最终状态(如果有的话)。如果没有找到该交易,它将返回 「UNKNOWN」。

新的 chain_api_plugin 端点

/v1/chain/get_transaction_status (get_transaction_status_params )

此端点接收交易ID ,并返回交易最终状态和有关交易的其他信息(如果有的话)。 有关语法,请参见A-2

交易资源成本估算

交易资源成本估算功能接收测试交易,并返回其估算的资源成本,而不需要将交易应用到链上。

此功能复制了Greymass一直在有效使用的解决方案,以估算其“Greymas Fuel”资源提供商的资源成本,这是防止意外资源超支故障的非常有用的工具。

它包括一个新的配置选项和一个新的API端点。

cleos 的新命令行选项

--read-only

此选项指定交易是「read-only」,不打算包含在区块链中。 当用户在启用此选项的情况下发送交易时,连接的节点将执行交易并恢复所有状态更改。

新的 chain_api_plugin 端点

compute_transaction

该节点端点接受并执行read-only交易,然后返回该交易的计算资源成本。它使用与旧的send_transaction参数相同的交易参数

该端点没有主观计费,因此运营商需要对该端点进行节流或限速,以防止 DDOS 攻击。

主观计费改进

节点的新配置参数

subjective-account-max-failures (默认值为3)

此配置参数控制三击规则(three-strikes rule)中使用的参数。 激活后,当账户在一个区块中发送了三个失败的交易后,节点将放弃该账户的所有排队交易。 操作者可以使用 subjective-account-max-failures 参数将最大失败次数由三次更改为其他次数。

subjective-account-decay-time-minutes (默认值为24小时)

此选项调整主观计费衰减时间,即将全部 CPU 时间返回到主观计费账户所需的时间。现有的主观计费余额使用时间为24小时的主观计费衰减窗口。

此衰减时间的精确机制涉及测量来自账户的资源消耗的指数移动平均值,以确定其剩余资源预算。 该协议将此剩余资源预算乘以自账户上次推送交易以来的主观衰减时间窗口的比例。

该公式(请参见 A-3)在数据丢失时使用账户资源使用情况的 EMA 和线性推断法,并将当前累积的平均值相乘:

测试发现,一小时(7200 个区块)可以在有效的速率限制和最小的 UX 影响之间取得平衡。

新的terminat-at-block选项

通过这个节点命令行选项,操作者可以配置节点,一旦它收到或复制了一个指定的区块号,就退出。在指定的区块退出,可以在无人看管的情况下进展到所需的状态,并支持预先确定的快照的轻松自动化。terminat-at-block选项在节点命令行中引入了一个可用的新参数。

节点的新配置参数:

--terminate-at-block <block#>(默认值为 0,表示禁用)

如果区块号设置为大于零,此选项将在达到提供的块号后终止节点实例。 此选项仅适用于命令行。

从合约中获取当前区块号

Mandel v3.1 版本引入了一个新的协议特性 GET_BLOCK_NUM,它使主机函数 get_block_num 在链激活时可供智能合约访问。get_block_num主机函数返回当前区块的区块号,或区块高度。

区块日志和 state_history_plugin (SHiP) 日志修剪

提供了两个新选项,block-log-retain-blocks 和 state-history-log-retain-blocks。 这些选项将节点配置为定期将这些日志修剪为最新配置的区块。 修剪允许节点操作者在不停止节点的情况下,随着时间的推移减少节点使用的磁盘空间。

block-log-retain-blocks 选项还为 eosio-blocklog 增加了 --vacuum 选项,它可以将修剪过的日志转换为未修剪的格式。未修剪的格式扩展了文件中在修剪过程中被折叠的稀疏区域,但并不恢复修剪过的数据。当节点操作者删除 block-log-retain-blocks 或 state-history-log-retain-blocks 选项时,会自动执行真空操作。

加密原语

Mandel v3.1 版本引入了一个名为 CRYPTO_PRIMITIVES 的新协议功能,它使合约在激活时可以访问七个新的主机函数。 这些函数都与加密计算相关,并降低了执行 EVM 预编译合约的 CPU 成本。

利用这些新的主机函数可以显著减少计算的执行时间,因为主机函数是在本机代码中实现的,没有智能合约的开销费用。 此功能启用以前超出交易期限的加密功能,并确保以较低的 CPU 成本访问其他功能。

  • 模块化指数计算的形式是 c=bx mod(m)。它将整数 b 乘以 x 次方,将结果除以整数,然后返回余数。 使用算术方法计算会变得越来越困难,因为当使用大的数字进行强加密时,bx会变得非常巨大。

例如,1024 位数字 51076 的 17 次方产生一个 1,304 位数字,算术方法必须除以该数字才能找到其余数。 对于大的数字结果来说,此过程很慢。 CRYPTO_PRIMITIVES 引入了一种算法,可以有效地对任何大小的数字进行这种模块化指数计算。

  • alt_ bn128是一条椭圆曲线,是一个一般形式为y2=x3+ax+b的多项式公式。CRYPTO_PRIMITIVES 在此曲线上引入了三个主机函数:
    • 点加法(alt_bn128_add)
    • 标量乘法 (alt_bn128_mul)
    • 双线性函数(alt_bn128_pair)

这些主机函数允许对零知识证明的zkSNARKS进行快速验证。

  • 该功能还引入了两个新的哈希函数,sha3 和 blake2_f。 
    • sha3是SHA2哈希算法的扩展,可更安全地抵御称为长度扩展攻击的特定类型的攻击,其中攻击者使用消息m1及其长度为m1 x m2的哈希函数解码另一条消息m2。sha3对这些攻击的抵抗力更强,sha3算法可以直接取代SHA2算法。
    • blake2_f是一个哈希函数,它提供了比sha3更快的哈希速度,将相对不安全的MD5算法的速度与sha3算法更高的安全级别结合起来。

这两个函数在零知识证明和其他保护隐私的数据验证方法中被广泛使用。

  • libsecp256k库是用于计算EOSIO公钥-私钥对的椭圆曲线的集合。Mandel 3.1版本包括对该库最新版本的更新,该版本将公钥恢复性能提高了33%。

EOSIO协议历来支持通过一个名为 recover_key 的主机函数为secp256k1和secp256r1椭圆曲线恢复ECDSA公钥。

新的k1_recover主机函数对recover_key进行了改进。当给定无效的签名时,它返回特定的失败条件,而不仅仅是一般的交易中止失败。

此外,它以非压缩格式返回记录的公钥,消减了椭圆曲线的数学步骤,减少了合约的大小和函数的CPU执行时间。

请注意,它只支持K1椭圆曲线,不支持R1椭圆曲线。

使用GELF日志协议支持用户定义的字段

GELF appender 现在支持 GELF logging.json 配置文件中的任意用户定义字段和值,但有以下限制:用户定义的字段名称必须以下划线开头,名称只能包含字母、数字、下划线、破折号、 和点。

除了格式检查之外,还有一个由规范保留或由节点使用的保留字段名称列表(参见 A-4)。

对字段名称长度、随附值或用户定义字段的数量没有强制限制。 但是,默认情况下,服务器将数据流限制为 128 个片段,每个片段 512 字节,因此服务器可能会根据其设置丢弃超过 65536 字节的消息。

GELF 协议强制执行类似的实际最大值,即 256 个 512 字节的片段,总计 131072 字节。

Graylog服务器在选择器和界面中显示用户定义的字段时,会自动省略前面的下划线。

Mandel v3.0版本的功能

Mandel v3.0版本包括EOSIO v2.1版本的几个功能,这些功能被移植到Mandel v3.0版本中。其中包括在操作跟踪中返回值的能力,WASM运行时间的可配置限制,以及其他可配置的区块链参数。Mandel v3.0版本的功能包括:

  • GET_CODE_HASH

允许合约检查账户是否有合约、合约的哈希值以及代码更改的次数。

  • ACTION_RETURN_VALUE

允许操作返回操作跟踪中的值。

  • CONFIGURABLE_WASM_LIMITS2

允许操作者增加对WASM文件的限制。

  • BLOCKCHAIN_PARAMETERS

允许配置区块链参数,如 ACTION_RETURN_VALUE 所支持的最大返回值。

  • onblock logging

帮助诊断系统合约故障。

有关这些功能的更多信息,请参见 Mandel v3.0.0 版本的发布页面

系统合约升级

Mandel v3.1版本引入了一个新的系统合约,即启动合约,以帮助启动一个新的区块链实例。这是必要的,因为要部署核心合约,系统需要访问使用某些协议函数激活的主机功能。除 preactivate_feature 外 ,所有主机功能在使用核心合约激活其函数之前均不可用。这就产生了一个激活悖论,阻碍了核心合约的部署。

启动合约只需要 preactivate_feature 主机函数,并包括一个可以激活部署核心合约所需的每个主机函数的函数。

核心系统合约也包括其他的新功能。

限制权限更改

核心合约中的一项新操作 limitauthchg ,允许账户选择性的限制权限更改。 使用它,账户可以对 updateauthdeleteauthlinkauth 和 unlinkauth 操作施加额外的限制。

limitauthchg 动作可以使用 allow_perms 或 disallow_perms 定义允许或不允许的权限。节点可以调用 limitauthchg的 allow_perms 或 disallow_perms 来选择加入该功能,但一个特定的调用不能同时包含 allow_perms 和 disallow_perms。如果定义了 allow_perms,那么就允许定义的权限执行更新、删除、链接和取消链接的授权操作。如果定义了 disallow_perms,那么定义的权限就不允许执行这些操作。

账户可以通过使用非空的 allow_perms 或 disallow_perms 调用 limitauthchg 操作来选择使用此功能。 他们可以通过使用空的 allow_perms 和 disallow_perms 调用 limitauthchg 操作来再次选择退出。

此功能有助于减轻拒绝服务攻击。具体而言,它可以防止涉及现有资源管理解决方案的攻击,该解决方案使用公开可用的私钥为应用程序的用户管理资源。

可配置的WASM限制

核心合约包括 CONFIGURABLE_WASM_LIMITS2 协议功能,以及调整 WASM 限制的操作 wasmcfg 。 wasmcfg 的有效值为 highlow 和 default, low 和 default 本质上是等同的。 将 wasmcfg 设置为 high,可以将可变全局变量使用的最大字节数增加 8 倍,表元素的最大数量增加 8 倍,最大可初始化内存范围增加 16 倍。 开发人员需要注意,如果在初始化合约时将此功能设置为 high,如果他们将该功能重置为 low 或 default,则可能会导致合约超出新的 WASM 限制并停止运行。

追踪最新的区块信息

引入了一个新的表,blockinfo,它包括表的版本号和最近10个区块的区块高度和时间戳。 get_latest_block_batch_info 函数返回给定批次的10个区块的开始区块和结束区块的高度和时间戳。如果这批次数据中的一个区块丢失,它将返回 「数据不足」。区块的缺失可能是由于提前删除了第一个块,或者是由于 onblock 操作的失败造成的间隙。如果批次起始高度大于最新区块高度,也会出现此错误。

其他更改

Memo备注字段现在可以在 setcode 和 setabi 操作中使用。 这允许合约开发人员直接在区块链上指定合约版本和发行说明。

setparams 操作有更多可用参数,包括 max_action_return_value_size,它用于 ACTION_RETURN_VALUE 协议功能。

新的系统合约包括修复REX中的一个四舍五入的错误,该错误使账户无法出售REX。它还包含一个补丁,其中包含冻结 B1 代币归属计划的系统合约变更。

合约开发工具包 (CDT)

合约开发工具包包括微小的变化和几个新功能。变化包括将名称从「eosio.cdt」改为「cdt」有关的几个重命名项目:

  • 修改二进制文件的名称,使它们的前缀是「cdt」而不是「eosio」,即从 eosio-cpp 变成 cdt-cpp 等等。
  • CMake 项目使用 find_package(cdt) 而不是 find_package(eosio.cdt)
  • 所有库的路径和命名空间都保持不变,但在未来的版本中可能会被分配到已废弃的功能。

Stack Canary

Stack Canary 是一个全新的 CDT 功能,当堆栈被放置在合约保留的内存部分的末端时,它可以防止堆栈溢出。 「Stack」是内存中随着进一步嵌套函数的调用而增长的部分。

当使用标志 -fno-stack-first 来允许较大的堆栈大小时,智能合约开发人员会面临意外结果或严重错误。通常情况下,CDT将堆栈放在一组可定位内存的开头。这有防止内存溢出的好处,因为堆栈溢出会溢出到合约数据中,并触发内存访问违规,导致程序终止,而不是造成意外的行为或严重的bug。但是,WASM 仅限于处理来自 WASM 内存的前 64kb 页的静态数据。这就限制了堆栈的大小为64KiB减去合约数据的大小,因为合约必须在前64KiB的内存中。

CDT 给了合约一个选择,将堆栈放在可定位内存的末端。这使得整个64KiB的首页向静态数据开放,允许更大的堆栈。然而,但是,这导致产生了堆栈溢出覆盖范围外内存的可能性。

为了缓解这种情况,CDT v3.0 版本添加了 -stack-canary 选项。 这为智能合约增加了一些保护,因此如果合约超出堆栈,它将使合约失败,而不可能让合约以意外结果结束。

为了解决这个问题,CDT 3.0.0引入了「Stack Canary」,它可以检测到堆栈溢出的情况并终止进程。这可以防止堆栈覆盖其范围之外的内存,提供与将堆栈保持在内存开头相同的好处,同时仍然允许更多的初始内存(全局变量和字符串)和更大的堆栈大小。

如果失败了,它将产生一个 8000000000000000002 的明确代码。

加密扩展

在 Mandel v3.1.0-rc2 版本中,添加了一组新的加密原语主机函数。 为了让智能合约开发人员能够利用这些函数,CDT v3.0 版本已将这些添加到开发人员的「C」API 中,其中一些添加到「C++」API 中。 有关这些函数的列表,请参阅 A-5

一些C++API包装器在本版本中被省略了,因为它们很快会被弃用。

这些新的函数和数据类型计划在下一个主要版本中发布。

Bug修复

由于构建问题,CDT v3.0 版本删除了使用 ccache 和 sccache 编译 CDT 的功能。

其他发布说明

新的构建过程

由 CMake 驱动的新构建过程,取代了之前推荐用于构建软件的 shell 脚本。 那些希望从源代码构建的人现在需要安装必要的依赖项。 依赖项列表和推荐的构建过程位于 README.md 文件中。 readme文件还包括有效运行测试的说明。

Ubuntu 18.04、20.04 和 22.04 是唯一受支持的构建平台。 其他发行版、编译器和平台也可以工作。 您的体验可能会有所不同。

兼容性

DUNE
快照兼容性

节点运营商可以使用快照更快地将节点与区块链的其余部分进行同步。

Mandel v3.1 版本引入的最新快照版本 v6 ,仅与 nodeos v3.1 兼容。 旧的 v4 快照与 Mandel v3.1 版本、EOSIO v2.0 版本和 EOSIO v2.1 版本兼容。

V5 快照来自不受支持的 EOSIO v2.1 版本,除非禁用 EOSIO v2.1 版本功能,否则无法与 Mandel v3.1 版本一起使用。

网络兼容性

网络兼容性是指节点通过节点之间的 p2p 连接接受区块和交易,并响应区块请求的能力。

该版本兼容运行EOSIO v2.0.x版本的网络及运行EOSIO v2.1版本的网络,只要该网络没有启用EOSIO v2.1版本的特定功能。

State_history_plugin 兼容性

Mandel v3.1 版本兼容 EOSIO v2.0 版本产生的区块日志和状态历史插件 (SHiP) 日志,但不兼容 EOSIO v2.1 版本。

Mandel v3.1版本的新功能要求更改状态历史ABI。Mandel v3.1 nodeos实例中状态历史的使用者必须准备好处理以下更改。

将发送一个新的 action_trace_v1 和 chain_config_v1,而不是之前的 _v0 版本。 客户必须准备好接收 v0 或 v1 版本,因为在升级到 Mandel v3.1 版本之前,他们将继续从状态历史日志中的条目中接收 v0 版本。

状态文件兼容性

此版本与早期版本生成的状态文件不兼容。 请使用从早期版本的节点生成的兼容快照文件来重建当前状态文件。

由之前的版本进行升级

从节点生成状态快照。 您不能使用来自 EOSIO v2.1 版本的快照,但来自 Mandel v3.0 或 v3.1 版本的快照,以及更早的快照版本都可以使用。 

删除升级节点所使用的状态文件。如果节点一直在使用EOSIO 2.1,操作者还必须删除SHiP和区块日志。如果节点从EOSIO v2.0版本升级,可以保留SHiP和区块日志。

用快照启动节点。之后,节点可像往常一样启动和停止。

弃用和删除

Mandel v3.1 版本从 EOSIO 中删除了一些已弃用的功能。 其中包括 history_plugin 和 mongoDB_plugin,两者都可以使用 state_history_plugin 或 trace_history_plugin 作为替代。 Mandel v3.1 版本还删除了 WABT,转而使用性能更高的 EOS VM。 它还放弃了对 Mac 的支持,尽管 Mac 和 Windows 用户仍然可以使用 DUNE 来虚拟 Mandel 区块链环境。

新的更新弃用了 cleos WAST 输出,以后的更新将删除它。

ABI 转换 API 已弃用

API /v1/chain/abi_bin_to_json 和 /v1/chain/abi_json_to_bin 在此版本中已被弃用,并将在未来版本中完全禁用或删除。 这是由于盲目信任这些 API 带来的安全风险,恶意行为者可以利用这些 API 在转换期间切换参数。

删除了构建脚本

如前所述,Mandel v3.1 版本从 EOSIO 中删除了构建脚本。 有关构建说明,请参阅 eosnetworkfoundation/mandel Github 存储库中的 README.md文件。

删除了history_plugin

作为EOSIO v1.2.0版本的一部分,history_plugin在2018年被弃用,Mandel v3.1版本完全删除了它。state_history_plugin 和 Hyperion 等 RAM 效率更高的解决方案已经取代了 history_plugin。

这意味着使用选项 --plugin eosio::history_plugin 初始化的节点应该转而使用选项 --plugin eosio::trace_api_plugin 或 --plugin eosio::state_history_plugin

删除了mongo_db_plugin

作为EOSIO v1.8.0版本的一部分,mongo_db_plugin 已被弃用,Mandel v3.1版本完全删除了它。

删除了Reversible区块数据库

在节点操作期间,chainbase数据库不再用于存储活动的reversible区块集。关闭时,reversible区块仍存储在fork数据库中。

注意:节点操作者应该从config.ini文件和任何脚本中删除 reversible 区块 Chainbase 数据库的所有现有配置,包括:

  • reversible-blocks-db-size-mb
  • reversible-blocks-db-guard-size-mb
  • fix-reversible-blocks
  • import-reversible-blocks 
  • export-reversible-blocks

取消了对 Ubuntu 16.04、Centos 和 MacOS 的支持

(支持 Ubuntu 18.04、20.04、22.04)(开发人员应使用 DUNE 用于 Windows、Mac 和任何支持 Docker 的 Linux 发行版)

UbunUbuntu 16.04、Centos 和 macOS

如前所述,唯一受官方支持的平台是Ubuntu 18.04、20.04和22.04。Mandel 已从二进制软件包支持和代码级更改中删除了所有其他版本,包括 Ubuntu 16.04、Centos 和 macOS。

在非Ubuntu机器上运行Mandel v3.1版本的开发者应该考虑使用DUNE,它支持Windows 10和11,macOS,以及任何支持Docker的Linux发行版。

弃用提案

弃用区块生产者的 r1 曲线和多键控制

由于缺乏使用,未来的版本可能会弃用区块生产者使用R1曲线来签署区块。

EOSIO 最初允许区块生产者注册多个具有多个权重的密钥,就像多个加权密钥可以控制账户一样。 它还允许区块生产者使用 k1 或 r1 曲线注册密钥。 这些是椭圆曲线加密学中使用的不同曲线。

官方文档指定 r1 曲线使用“可验证的随机”曲线。 比特币粉丝普遍推测,比特币的创造者中本聪不相信这条「可验证的随机」曲线没有潜在的后门。 由于这种不信任和 secp256k1 曲线的效率,比特币使用了 k1 曲线。

EOS 上的区块生产者不使用 r1 曲线上的密钥或多密钥区块生产。 该寻求反馈的开放 Github 问题建议放弃对 r1 椭圆曲线上的密钥的支持,并放弃多密钥生产者权限。

用通用的HSM支持替换YubiHSM支持

EOSIO v1.7版附带了一个工具,允许用户使用YubiKey硬件认证设备在EOSIO工具keosd上轻松创建密钥。该提案指出了该工具附带的不必要的依赖性和软件集成障碍,并提出了一种与任何通用硬件认证设备兼容的替代工具,其中包括YubiKey。

这种替代方案需要一种新的工具,以便于将双用户通用工具顺利集成到单用户keosd环境中。

附录

A-1 新的 send_transaction2 端点结构:

该端点具有以下结构:

struct send_transaction2_params {

    bool return_failure_trace = true; ///< Embed transaction exceptions into the returned transaction trace

    bool retry_trx = false; ///< request transaction retry on validated transaction

    std::optional<uint16_t> retry_trx_num_blocks{}; ///< if retry_trx, report trace at specified blocks from executed or lib if not specified

    fc::variant transaction; ///< same format as send_transaction
};

A-2 交易终结状态端点的语法

该端点的语法如下:

struct get_transaction_status_params {
      string id; //transaction id to status
 };
 struct get_transaction_status_results {
    string state;
    std::optional<uint32_t> block_number;
    std::optional<chain::block_id_type> block_id;
    std::optional<fc::time_point> block_timestamp;
    std::optional<fc::time_point> expiration;
    uint32_t head_number;
    chain::block_id_type head_id;
    fc::time_point head_timestamp;
    uint32_t irreversible_number;
    chain::block_id_type irreversible_id;
    fc::time_point irreversible_timestamp;
    chain::block_id_type last_tracked_block_id;
};

A-3 资源成本计算

该计算使用账户链利用率的指数移动平均值,在给定有限数据时使用线性外推法。它将当前累积的平均数乘以(窗口中的区块数-上次更新后的区块数)/(窗口中的区块数)。

EMA 是针对窗口中的每个周期计算的,如此:

EMA = 指数移动平均值

kk = 加权乘数,k = 2N + 1 其中 N = 时间窗口中的周期数

pc=本期收盘价

EMAp = 上一期的 EMA,第一期的 EMA = 时间窗口的 SMA

公式为:

EMA从第一个周期开始,一次计算一个周期。第一个周期的均线与SMA(简单移动平均值)相同,后者使用以下典型平均公式:

其中 n 是窗口中的周期数,A 是每个周期的值。

A-4 GELF 保留字段:

保留字段名称列表为:

_id
_timestamp_ns
_log_id
_line
_file
_method_name
_thread_name
_task_name

A-5 用于加密扩展的新 C 和 C++ API 函数:

C API 现在具有以下函数:

void sha3( const char*, uint32_t, char*, uint32_t , int32_t)
int32_t blake2_f(uint32_t, const char*, uint32_t, const char*, uint32_t, const char*, uint32_t, const char*, uint32_t, int32_t, char* , uint32_t)
int32_t k1_recover( const char*, uint32_t, const char*, uint32_t, char*, uint32_t)
int32_t alt_bn128_add( const char*, uint32_t, const char*, uint32_t, char*, uint32_t)
int32_t alt_bn128_mul( const char*, uint32_t, const char*, uint32_t, char*, uint32_t)
int32_t alt_bn128_pair( const char*, uint32_t)
int32_t mod_exp( const char*, uint32_t, const char*, uint32_t, const char*, uint32_t, char*, uint32_t)
uint32_t get_block_num( void )

C++ API 现在具有以下函数:

block_num_t current_block_number() - (in system.hpp)
eosio::checksum256 sha3(const char*, uint32_t) - (in crypto.hpp)
eosio::checksum256 keccak(const char*, uint32_t) - (in crypto.hpp)
void assert_sha3(const char*, uint32_t, eosio::checksum256&) - (in crypto.hpp)
void assert_keccak(const char*, uint32_t, eosio::checksum256&) - (in crypto.hpp)

关于EOS网络

EOS网络是区块链3.0时代的典范之作,由EOS VM提供支持。EOS VM是一个低延迟、高性能和可扩展的WebAssembly引擎,能够近乎无感的实现确定性交易执行。EOS网络专为Web 3设计,致力于实现最佳的Web 3用户和开发人员体验。EOS是EOSIO协议的旗舰区块链和金融中心,并通过EOS网络基金会(ENF)作为多链协作和发展公共基础产品的工具,进一步完善基础设施,驱动EOS快速发展。

EOS网络基金会

EOS网络基金会是一个非营利性的组织,旨在倾听社区声音、传达社区意愿并扶持社区优质项目发展,成为EOS社区的信息共享桥梁,并为EOS生态提供资金、技术、运营、未来规划、生态构建等关键基础设施支持,进一步发挥EOS作为世界速度最快的治理型区块链的全部潜力。

原文/Original:

The Mandel v3.1 release blockchain software distills months of research and development into a network upgrade that is full of useful features and fixes. 

The Blue Papers outlined some of these features. The API+ Blue Paper recommended several improvements to mitigate lost transactions and improve the predictability of transaction lifecycles.

Previous articles explored how the subjective billing system can cause lost transactions and outlined existing fixes for common transaction lifecycle issues like lost transactions. The Mandel v3.1 release introduces new tools to address these issues and other user experience hurdles. 

The Mandel v3.1 release introduces the following new transaction lifecycle tools: 
Additional Mandel upgrades that are not focused on transaction lifecycle include:
Mandel removes
  • The history plugin, which was deprecated in 1.2 
  • MongoDB plugin
  • Older Build scripts
  • Reversible block database
  • Support for macOS and alternate Linux distributions. The Mandel v3.1 release only officially supports Ubuntu 18.04, 20.04, and 22.04. 
  • It also deprecates the abi_bin_to_json and abi_json_to_bin conversion APIs.

Like EOSIO 1.8, the Mandel v3.1 release requires a coordinated protocol activation. Nodes must update binaries and change configuration settings, and nodes running EOSIO 2.1 must take additional steps before block producers activate new protocol features. Operators need to complete these steps by the planned upgrade date of 21 September 2022. Any nodes that do not activate the Mandel v3.1 release are unable to sync with the rest of the network after 21 September. 

You can find more detail about these upgrade steps in our upgrade guide.

New Mandel v3.1 Release Features

Transaction Failure Tracing and New Transaction Endpoint

(Details)

The Mandel v3.1 release introduces a new transaction endpoint that includes a detailed failure report with embedded transaction exceptions when a transaction fails. This detailed report is the transaction failure trace. Do not mistake this report for a successful transaction trace. You may want to verify the receipt and except fields to ensure transaction success.

Prior to the Mandel v3.1 release, failed transactions resulted in a transaction failure trace without details of the failure. A Mandel v3.1 transaction failure trace specifies where in a transaction the failure occurred and identifies which action produced the failure. The new Mandel v3.1 transaction endpoint has this feature enabled by default.

Transaction Retry

(Details)

The transaction retry feature allows API nodes to resubmit lost transactions additional times until they appear in a block or expire. 

For background, when a user connects to an API node and sends a transaction to the network, there is no guarantee that the transaction will successfully make it into a block. 

Many issues, such as subjective billing or geographic latency, can prevent the propagation of a transaction across the network to the active block producer. One way to solve these issues is to allow API nodes to track transactions for inclusion in the blockchain and retry transactions that block producers did not publish in a block.

The transaction retry featurecreates an incoming transaction pool and temporarily keeps transactions in the pool. After inclusion in a block, the transaction remains in the pool for a set number of blocks or until that block reaches irreversibility. 

Node operators individually set the transaction pool parameters and the criteria that define a missing transaction. If the tool detects a missing transaction based on those criteria, it will resubmit the transaction to the network. 

Transaction Finality Status

(Details)

The transaction finality status feature allows nodes to share the finality status of a given transaction. It also returns snapshots of the current chain state.

One of the most common functions developers implement in their smart contracts is to check a transaction’s finality status. With current tooling, each developer must build a custom solution. The need to build and rebuild transaction finality status increases development time and adds a vector for smart contract exploits and bugs. There is great value in allowing nodes to provide this transaction finality information directly.

The transaction finality status feature allows nodes to share snapshots of the current chain state. Nodes with this feature enabled can store transaction status and open a new endpoint to query that status. It returns a status of “UNKNOWN” if the transaction does not appear in the chain.

Transaction Resource Cost Estimation

(Details)

The transaction resource cost estimation feature lets nodes open a read-only endpoint that returns an estimate of resource costs. 

In EOSIO chains, the active block producer determines the cost of a transaction at execution time. The block producer determines CPU cost by measuring the CPU time used to execute the non-signature portion of the transaction. The variance in block producer CPU performance makes it difficult to determine actual resource costs before sending a transaction.

The transaction resource cost estimation feature helps users and applications more accurately estimate the resource costs of a transaction. The resource cost estimation feature creates an API endpoint to receive an unsigned transaction. A node with the feature enabled returns an estimate of the transaction’s resource costs based on how long the API node takes to process the transaction. 

Subjective Billing Improvements

(Details)

The Mandel v3.1 release’s subjective billing improvements consist of changes to two existing tools. The first change allows nodes to adjust the subjective billing decay time from its default of 24 hours. The second change allows API nodes to use the three-strikes rule, as used by block producers, and allows adjustment of the three-strikes parameter.

Because EOSIO chains only charge accounts when a block producer publishes a transaction to the blockchain, failed transactions are effectively free, sometimes leading to abuse. The three-strikes rule and the subjective billing tool reduce the failed transaction load on nodes, but introduce user experience hurdles. Mandel introduces adjustable subjective billing and three-strikes parameters to mitigate these user experience hurdles. 

Account max failures: 

Before subjective billing, EOSIO 2.0.9 implemented the three-strikes rule for block producer nodes. The three-strikes feature drops the rest of an account’s queued transactions when the account has sent three failed transactions within a single block, reducing the burden of failed transactions.

In the Mandel v3.1 release, API nodes can now use this feature. The previously hard-coded limit of 3 is also now configurable to any number of failures.

In addition, accounts that have been whitelisted with the disable-subjective-account-billing option no longer encounter the max transaction failure limit.

Subjective account decay:

Nodes prevent excessive failed transactions by using subjective billing to track an account’s failed transaction CPU budget for each node. The protocol returns this budget to an account over a period known as subjective account decay. This previously hard-coded decay of 24 hours is now configurable.

With the current 24-hour time window, for an account that hasn’t pushed a transaction in 6 hours, the node applies a multiplier of 6/24, or ¼, providing only 25% of the account’s otherwise available resources. 

When the time window is adjusted to 6 hours, the node applies a multiplier of 6/6, or 1, which gives the same account 100% of the available resources. 

When the window is set to one hour, tests find the one-hour window is effective at failed transaction spam mitigation without user experience issues.

Additional Features: 

Additional new features include cryptography-related improvements, new protocol options, pruning features, and logging improvements. Some features optimize EVM-related considerations, while network participants requested other features to improve the efficiencies of their workflows.

CRYPTO_PRIMITIVES is a feature that introduces seven new host functions. Host functions are faster than smart contracts because they are implemented in native code rather than in an abstracted smart contract layer. These functions enable more efficient computation of the cryptographic functions used in many Solidity and EVM-based contract libraries. The new feature includes:

  • An algorithm that more efficiently performs modular exponentiation ( c=modm(bx) ), a useful formula for hashing algorithms.
  • Three functions on the alt_bn128 elliptic curve:
    • Point addition
    • Scalar multiplication
    • Bilinear functions 
  • Two new hash functions:
    • sha3
    • blake2_f

Both functions are used extensively in zero-knowledge proofs and other privacy-preserving data verification methods.

  • Upgrades to the libsecp256k library, improving k1 key recovery by 33%.

The Mandel v3.1 release adds nodeos options to prune the block log and state history plugin. When nodeos prunes these files, it removes older data from local node storage to improve performance. 

It also introduces the option to terminate at a particular block, which is useful for chain state snapshots.

Additionally, it includes user-defined fields for transaction logs on a protocol called GELF. This protocol allows transaction logs to be shared using a common syntax that operators can easily integrate with other transaction log solutions.

As an added feature for smart contract developers, Mandel allows contracts to fetch the current block number directly. 

The upgrade also incorporates and improves upon several features that were included in the EOSIO v2.1 release, which includes configurable WASM limits and other blockchain parameters. It also adds the get_code_hash and action_return_value intrinsics from the EOSIO v2.1 release.

Updates from the Mandel v3.0 release

(Details)

The Mandel v3.0 release included several features from the EOSIO v2.1 release, in addition to new features and various changes to tests, logs, and formats. These features were largely added to bring Mandel features up to date with features from the EOSIO v2.1 release, while omitting those EOSIO v2.1 features that the network didn’t need. Additional features have been added to improve efficiency and facilitate various upgrades in the Mandel v3.1 release.

  • GET_CODE_HASH
  • ACTION_RETURN_VALUE
  • CONFIGURABLE_WASM_LIMITS2
  • BLOCKCHAIN_PARAMETERS

System Contract

(Details)

The Mandel v3.1 release updates the core system contracts and introduces a new boot contract to streamline testing. System contract upgrades do not require a coordinated consensus upgrade.

The boot contract is a new system contract that helps bootstrap a new blockchain. It resolves a set of circular dependencies that prevents operators from initializing a new chain. The core system contract requires specific protocol features, and prior to the boot contract, those features required the core system contract for activation. The boot contract circumvents this issue. It provides an alternate means to activate specific protocol features that are necessary for the core system contract and do not have dependencies. When a new chain activates this boot contract on a new chain, it allows activation of the core system contract and then of individual protocol features.

In addition, the core system contracts now allow for:

  • Configurable WASM limits 
  • Memo fields in setabi and setcode 
  • The ability to restrict permission changes
  • A blockinfo table that tracks the 10 most recent blocks 
  • Updates to adjustable blockchain parameters
  • Various bug fixes and patches.

Contract Development Toolkit (CDT)

(Details)

The Contract Development Toolkit (CDT) upgrade is a suite of tools that smart contract developers can use to translate their contracts to WebAssembly, Mandel’s native codebase. CDT version 3.0.0 implements several changes to this tool. 

Developers need to be aware that this release changes the toolkit’s name from “eosio.cdt” to just “cdt”. Developers need to change their CMake files and replace each instance of “eosio.cdt” with “cdt” to accommodate this change.

The CDT adds C++ wrappers for crypto primitives, to allow contracts to use these primitives. The currently released wrappers are for the SHA3 algorithm and the current block number, but other C++ wrappers will be added later.

The CDT also includes the new Stack Canary feature that prevents stack overflows.

Installation

The Mandel v3.1 release makes changes to the installation procedure of the core software. It also has several compatibility differences as compared to previously released updates.

The new build procedure uses a build process driven by CMake instead of custom shell scripts. Without these build scripts, a build from the source code requires the installation of necessary dependencies. The readme lists these dependencies and the recommended build procedure. 

The Mandel v3.1 release is built for Ubuntu 20.04 and 22.04, with support for Ubuntu 18.04, although other distributions, compilers, and platforms may work.

Upgrading from Prior Releases

To upgrade a node using a snapshot: 

  1. First, generate a state snapshot from a compatible earlier version of nodeos, such as the nodeos version from the EOSIO v2.0 release. 
  2. Remove the node’s state file. 
  3. If the node uses the EOSIO v2.1 release, operators also must remove the SHiP and block logs. Nodes running the EOSIO v2.0 release do not need to take this step.
  4. Start nodeos with the snapshot. 
  5. Start and stop nodeos as usual.

For more details or advice on more complex situations, refer to our Upgrade Guide or contact EOS Support for further recommendations.

Compatibility

(Details)

In general, the Mandel v3.1 release is compatible with networks, snapshots, block logs, and state history plugin (SHiP) logs from the EOSIO v2.0 release, but NOT the EOSIO v2.1 release.

The Mandel v3.1 release is NOT compatible with state files from earlier software versions.

Docker Utilities for Node Execution (DUNE)

DUNE is an environment designed to run on macOS, Windows 10 & 11, and other operating systems that the Mandel v3.1 release does not directly support. DUNE requires Docker and Python3, but is otherwise straightforward to implement, with instructions for each operating system in the readme. It offers the same commands as nodeoscleoscdt, and other Mandel v3.1 components. It also offers other abstracted commands that involve all of these components. Importantly, it allows anyone with a Docker-capable machine to develop and test on the EOS network.

Mandel v3.1 release Deprecations & Removals

(Details)

The Mandel v3.1 release deprecates the ABI conversion APIs and removes several deprecated features. 

ABI conversion APIs are deprecated.

The abi_bin_to_json and abi_json_to_bin conversion APIs turn serialized data into deserialized data or vice versa. They are both deprecated as of the Mandel v3.1 release.

Several features are removed:

  • Old Build Scripts

The Mandel v3.1 release removes the build scripts that install nodeoscleoskeosd, and their dependencies. The new CMAKE script installs only nodeoscleos, and keosd, and operators must install dependencies first.

  • History Plugin

The EOSIO v1.0 release included a history plugin, but EOSIO v1.2 deprecated this history plugin on August 14, 2018 in favour of more performant solutions. It will be removed in the Mandel v3.1 release, and nodes using --plugin eosio::history_plugin should migrate to --plugin eosio::trace_api_plugin or --plugin eosio::state_history_plugin

  • MongoDB Plugin

The EOSIO v1.8 release deprecated the MongoDB plugin, which allowed nodes to archive blockchain data into a MongoDB database. The Mandel v3.1 release removes this plugin entirely. Node operators can use history tools like the state_history_plugininstead.

  • Reversible Block Database

The Mandel v3.1 release removes the reversible block database, and stores reversible blocks in the fork database instead. Operators should remove existing configuration settings for the reversible block database from the config.ini file and any scripts.

Dropped support for Ubuntu 16.04, Centos, and MacOS

The Mandel v3.1 release drops support for MacOS, Ubuntu v16.04, and the CentOS Linux distribution to optimize developer resources. Supported platforms are now Ubuntu 18.04 (limited support), 20.04, and 22.04. For users on one of these unsupported operating systems, DUNE offers compatibility for any Docker-compatible OS.

Conclusion

The Mandel v3.1 release includes powerful tools and options to improve the functionality and user experience on EOS and other EOSIO-based blockchains. As a protocol upgrade, it requires coordination between node operators as the anticipated activation date of 21 September 2022 approaches. After this date, block producers will have updated their software, and wallets and applications can begin incorporating features from the Mandel v3.1 release. With the completion of this network upgrade, the EOS Network will make its first strides into self-sovereign network development, making the best technology in the blockchain business even better.

Detailed Release Notes

New Transaction Endpoint

The new chain_api_plugin endpoint feature incorporates transaction_retry as well as other parameters for future features. The endpoint is:

/v1/chain/send_transaction2 (send_transaction_params)

It is similar to the send_transaction endpoint but with additional options. It has the option to return a failure trace and the option to retry a transaction. It has the same format as send_transaction, save for the new configuration arguments (See A-1).

Transaction Retry

The transaction retry feature comes with new configuration arguments for nodeos and new command-line options for the cleos interface.

Configuration arguments are used to adjust the behavior of nodes, and can be used in the config.ini configuration file or directly in nodeos. Config files should have configuration items formatted as “option = value” while command line items can be formatted as “--option=value” or “--option value”. The new transaction retry arguments node operators can use in config.ini files or when starting an instance of nodeos consist of:

transaction-retry-max-storage-size-gb

This option sets the maximum storage space allocation (in GiB) allowed for the transaction retry feature. Setting this number above 0 enables this feature. Nodes with the feature disabled will reject transactions that request it.

transaction-retry-interval-sec (defaults to 20)

This option sets how often, in seconds, a node should re-send an incoming transaction to the P2P network if it doesn’t detect the transaction in a block.

transaction-retry-max-expiration-sec (defaults to 90)

This option sets the maximum allowed transaction expiration time for transactions in the retry pool. The transaction retry tool will not add transactions to the pool if they have an expiration time above this value.

p2p-dedup-cache-expire-time-sec (defaults to 10)

This option sets the deduplication cache. Adjusting this number adjusts the maximum time in seconds to keep track of a transaction while removing its duplicates from the transaction pool.

 The new command-line options for users interacting with the blockchain through cleos consist of:

--use-old-send-rpc (T/F)

This option forces cleos to use the older transaction formatting, using send_transaction instead of send_transaction2 with its new features. It is useful for testing and debugging old APIs.

-t--return-failure-trace (T/F)

This option returns information on failed transactions to the user. It improves debugging, allowing users to see which specific action failed.

--retry-irreversible (T/F)

This option allows transaction signers to request that nodes retry a transaction until it is in an irreversible block or until the transaction expires. It is a blocking call. It will return an error if the node does not have the feature enabled.

--retry-num-blocks (T/F)

This option allows transaction signers to request that nodes retry a transaction until it has been seen in a block with a defined number of blocks ahead of it or until the transaction expires. It is a blocking call. It will return an error if the node does not have the feature enabled.

Transaction Finality Status

The transaction finality status feature returns a transaction’s status in response to requests. The tool stores transactions propagated by a node in a transaction pool until a transaction is expired or finalized for a specified number of blocks.

It includes the following arguments:

transaction-finality-status-max-storage-size-gb 

This option sets the transaction finality status pool’s storage size (in GiB). Nodes will drop older transactions when the pool size hits this limit. Setting it above zero enables this feature. Nodes with the feature disabled will reject transactions that request it.

transaction-finality-status-success-duration-sec

This option defines the length of time (in seconds) after a successful transaction has achieved finality that it will be kept in the transaction finality status pool.

transaction-finality-status-failure-duration-sec

This option defines the length of time (in seconds) after a failed transaction has reached its expiration time that it will be kept in the transaction finality status pool. 

New command-line options for cleos

get transaction-status <id>

This option allows a node, given a transaction ID, to return the current blockchain state and information on the transaction ID, including its finality status if available. It will return “UNKNOWN” if the transaction is not found.

New chain_api_plugin endpoint

/v1/chain/get_transaction_status (get_transaction_status_params )

This endpoint receives a transaction ID and returns the transaction finality state and other information about the transaction, if it is available. See A-2 for the syntax.

Transaction Resource Cost Estimation

The transaction resource cost estimation feature receives test transactions and returns their estimated resource costs without applying the transaction to the chain.

This feature replicates a solution Greymass has been using effectively to estimate resource costs for their ‘Greymass Fuel’ resource provider, which has been a tremendously helpful tool for preventing unintentional resource overrun failures. 

It includes one new configuration option and one new API endpoint.

New command-line option for cleos

--read-only

This option specifies that a transaction is “read-only” and not intended for inclusion in the blockchain. When a user sends a transaction with this option enabled, the connected node will execute the transaction and revert any state changes. 

New chain_api_plugin endpoint

compute_transaction

This node endpoint accepts and executes read-only transactions and then returns the computed resource costs for the transaction. It uses the same transaction parameters as the old send_transaction parameters.

Subjective Billing Improvements

New configuration args for nodeos

subjective-account-max-failures (default 3)

This configuration argument controls parameters used in the three-strikes rule. When activated, nodes will drop all queued transactions from an account after the account has sent three failed transactions in one block. Operators can change the maximum number of failures from three with the subjective-account-max-failures parameter.

subjective-account-decay-time-minutes (default 24 hours)

This option adjusts the subjective billing decay time, the time it takes to return full CPU time to subjectively billed accounts. Existing subjective billing balances use a 24-hour subjective billing decay window. 

The precise mechanism of this decay time involves measuring the exponential moving average of resource consumption from an account to determine its remaining resource budget. The protocol multiplies this remaining resource budget by the proportion of the subjective decay time window since the account last pushed a transaction. 

The formula (see A-3) uses the EMA of an account’s resource usage with linear extrapolation when data is missing, and it multiplies the currently accumulated average by:

Testing has found one hour (7200 blocks) to provide a balance between effective rate-limiting and minimal UX impact.

New terminate-at-block option.

With this nodeos command-line option, operators can configure nodeos to exit once it receives or replays a specified block number. Exiting at a specified block allows unattended progression to a desired state, and enables easy automation of pre-determined snapshots. The terminate-at-block option introduces one new parameter available in the nodeos command line.

New configuration arg for nodeos:

--terminate-at-block <block#>(defaults to 0, meaning disabled)

This option will terminate the nodeos instance after reaching the supplied block number, if the block number is set above zero. This option only works on the command line.

Get the current block number from within a contract.

The Mandel v3.1 release introduces a new protocol feature GET_BLOCK_NUM, which makes the host function get_block_num accessible to smart contracts when the chain activates it. Theget_block_num host function returns the block number, or block height, of the current block.

Block Log & state_history_plugin (SHiP) Log Pruning

Two new options, block-log-retain-blocks and state-history-log-retain-blocks, are available. These options configure nodeos to periodically prune these logs to the most recent configured blocks. Pruning allows node operators to reduce the amount of disk space nodeos uses over time without stopping the node.

The block-log-retain-blocks option also adds the --vacuumoption to eosio-blocklog, which converts a pruned log into an unpruned format. The unpruned format expands sparse areas of the file that were collapsed during pruning, but doesn’t restore pruned data. The vacuum operation is automatically performed when a node operator removes the block-log-retain-blocks or state-history-log-retain-blocks options.

Crypto Primitives

The Mandel v3.1 release introduces a new protocol feature called CRYPTO_PRIMITIVES, which makes seven new host functions accessible to contracts upon activation. These functions are all related to cryptographic computations and reduce the CPU costs of executing EVM precompiled contracts.

Leveraging these new host functions may significantly reduce execution time for their computations, because the host functions are implemented in native code without the overhead of a smart contract. This feature enables cryptographic functions that previously overran transaction deadlines, and ensures accessibility of other functions at a lower CPU cost.

  • Modular exponentiation takes the form c=bx mod(m). It raises an integer b by a power x, divides the result by an integer, and returns the remainder. Computation can quickly become difficult using arithmetic methods, as bx gets enormous when using large numbers for strong cryptography. 

For example, the 1024-bit number 51076 raised to the 17th power produces a 1,304-digit number that arithmetic methods must divide to find its remainder. This process is slow for large numbers. CRYPTO_PRIMITIVESintroduces an algorithm that does this kind of modular exponentiation efficiently for any size number.

  • alt_bn128 is an elliptic curve, a polynomial formula of the general form y2=x3+ax+b. CRYPTO_PRIMITIVES introduces three host functions on this curve: 
    • point addition (alt_bn128_add)
    • scalar multiplication (alt_bn128_mul)
    • bilinear functions (alt_bn128_pair)

These host functions allow for the rapid verification of zkSNARKS for zero-knowledge proofs.

  • The feature also introduces two new hash functions, sha3 and blake2_f
    • sha3 is an extension of the SHA2 hashing algorithm that is more secure against particular types of attacks known as length-extension attacks, where an attacker uses a message m1 and its length to decode another message m2 from the hashing function of m1 x m2. SHA3 is much more resistant to these attacks, and SHA3 algorithms can directly replace SHA2 algorithms. 
    • blake2_f is a hashing function that offers faster hashing speeds than sha3, combining the speed of the relatively insecure MD5 algorithm with the higher security level of the SHA3 algorithm.

Both functions are used extensively in zero-knowledge proofs and other privacy-preserving data verification methods.

  • The libsecp256k library is a collection of elliptical curves used in computing EOSIO public-private key pairs. The Mandel 3.1 release includes an update to a more recent version of this library that improves the performance of public-key recovery by 33%. 

The EOSIO protocol has historically supported ECDSA public key recovery for the secp256k1 and secp256r1 elliptic curves through a host function called recover_key

The new k1_recover host function improves on recover_key. It returns the specific failure condition when given an invalid signature, rather than just a generic transaction abort failure.

In addition, it returns the recorded public key in uncompressed format, eliminating an elliptical curve mathematics step and reducing contract size and CPU execution time for the function.

Notably, it only supports the K1 elliptical curve and not the R1 elliptical curve.

Support for user-defined fields with the GELF logging protocol.

The GELF appender now supports arbitrary user-defined fields and values in the GELF logging.json configuration file, with the following restrictions: user-defined field names must begin with an underscore, and names can contain only letters, numbers, underscores, dashes, and dots. 

Beyond the format check, there is also a list of reserved field names reserved by the specification or used by nodeos (see A-4). 

There is no enforced limit on the field name length, the accompanying value, or the number of user-defined fields. However, by default, servers limit streams to 128 fragments of 512 bytes each, so messages over 65536 bytes might be dropped by the server based on its settings.

The GELF protocol enforces a similar practical maximum of 256 fragments of 512 bytes, totalling 131072 bytes.

The Graylog server automatically omits the leading underscore in user-defined fields when displaying them in selectors and the interface.

Mandel v3.0 Release Features

The Mandel v3.0 release included several features from the EOSIO v2.1 release that were ported to the Mandel v3.0 release. Among these are the ability to return a value in the action trace, configurable limits for a WASM runtime, and other configurable blockchain parameters. The features from the Mandel v3.0 release include:

  • GET_CODE_HASH

Allows contracts to check if an account has a contract, the contract’s hash, and how many times the code has changed.

  • ACTION_RETURN_VALUE

Allows actions to return values in the action trace.

  • CONFIGURABLE_WASM_LIMITS2

Allows operators to increase limits on WASM files. 

  • BLOCKCHAIN_PARAMETERS

Allows the configuration of blockchain parameters like the maximum return value supported by ACTION_RETURN_VALUE.

  • onblock logging

Helps diagnose system contract failures.

More info on these features can be found in the release page for the Mandel v3.0.0 release.

System Contract Upgrades

The Mandel v3.1 release introduces a new system contract, the boot contract, to aid in bootstrapping a new blockchain instance. This is necessary because to deploy the core contract the system needs to access host functions that are activated with certain protocol features. All host functions except preactivate_feature are unavailable until their features are activated using the core contract. This creates an activation paradox, preventing deployment of the core contract. 

The boot contract requires only the preactivate_feature host function, and includes a function that can activate each of the host functions needed to deploy the core contract. 

The core system contract includes new features as well. 

Restricting Permissions Changes

One new action in the core contract, limitauthchg, allows accounts to optionally restrict permission changes. Using this, accounts can put additional constraints on the updateauthdeleteauthlinkauth, and unlinkauthactions.

The limitauthchg action can define which permissions to either allow or disallow using either allow_perms or disallow_perms. Nodes can call limitauthchgfor allow_perms or disallow_permsto opt into the feature, but a given call cannot contain both allow_perms and disallow_perms. If allow_perms are defined, then the defined permissions are permitted to perform update, delete, link, and unlink authorization actions. If disallow_perms are defined, then the defined permissions are not permitted to perform these actions.

Accounts can opt into this feature by calling the limitauthchg action with non-empty allow_permsor disallow_perms. They can opt out again by calling the limitauthchg action with empty allow_perms and disallow_perms

This feature is helpful for mitigating denial-of-service attacks. Specifically, it can prevent attacks involving an existing resource management solution that uses a publicly available private key to manage resources for an application’s users.

Configurable WASM Limit

The core contract includes the CONFIGURABLE_WASM_LIMITS2 protocol feature, and an action wasmcfg that adjusts the WASM limit. Valid values of wasmcfgare highlow, and default, although low and default are equivalent. Set wasmcfg as high to increase the maximum bytes used for mutable globals by 8x, the maximum number of table elements by 8x, and the maximum initializable memory range by 16x. Developers need to be aware that if this feature is set to high when a contract is initialized, if they reset the feature to lowor default it may cause the contract to overrun the new WASM limit and cease to function.

Tracking Recent Block Info

A new table has been introduced, blockinfo, which includes the table version number with the block height and timestamp of the 10 most recent blocks. The get_latest_block_batch_info function returns the block height and timestamp of the starting and ending block of a given batch of 10 blocks. It returns “insufficient data” if one of the blocks within this batch is missing. Blocks may be missing due to either early deletion of the first block or gaps caused by failure of the onblock action. This error will also occur if the batch start height is greater than the latest block height.

Additional changes

Memo fields are now available in the setcode and setabi actions. This allows contract developers to specify contract versions and release notes directly on the blockchain.

The setparams action has more parameters available, including max_action_return_value_size, which is used in the ACTION_RETURN_VALUEprotocol feature.

The new system contracts include a fix to a rounding error bug in REX that prevented accounts from selling REX. It also features a patch that incorporates the system contract change that resulted in freezing B1’s token vesting schedule.

Contract Development Toolkit (CDT)

The Contract Development Toolkit includes minor changes and several new features. Changes include a few renaming items related to changing the name from “eosio.cdt” to just “cdt”:

  • Name changes to the binaries, so that they have a prefix of “cdt” rather than “eosio” i.e. eosio-cpp becomes cdt-cpp etc.
  • CMake projects use find_package(cdt) instead of find_package(eosio.cdt).
  • All library paths and namespaces remain the same, but may be assigned to deprecated features in a future release.

Stack Canary

Stack Canary is a brand new CDT feature that prevents stack overflows when the stack is placed at the end of the contract’s reserved portion of memory. The “stack” is the portion of the memory that grows as further nested functions are called. 

When using the flag -fno-stack-first to allow for large stack sizes, smart contract developers open themselves up to unexpected results or severe bugs. Normally, CDT places the stack at the beginning of a set of addressable memory. This has the benefit of preventing memory overruns, as stack overflows will spill into the contract data and trigger a memory access violation, causing the program to terminate rather than causing unexpected behavior or severe bugs. However, WASM is limited to processing static data from only the first 64kb page of WASM memory. This limits the size of the stack to 64KiB minus the size of the contract data, as the contract must be within the first 64KiB of memory. 

CDT gives contracts the option to place the stack at the end of addressable memory. This opens the entire 64KiB first page to static data, allowing for a larger stack. However, this introduces the possibility of a stack overflow overwriting out-of-scope memory. 

To mitigate this, the CDT v3.0 release adds the -stack-canary option. This adds some protection to smart contracts, so if a contract overbounds the stack, it will fail the contract instead of possibly allowing it to finish with unexpected results.

To fix this, CDT 3.0.0 introduces the “Stack Canary”, which detects when a stack overflow occurs and terminates the process. This prevents the stack from overwriting memory outside of its scope, providing the same benefits as keeping the stack at the beginning of memory, while still allowing for more initial memory (global variables and strings) and larger stack sizes.

If this fails it will produce an assertion code of 8000000000000000002.

Crypto Extensions

In the Mandel v3.1.0-rc2 release a new set of crypto primitive host functions have been added. To allow smart contract developers the ability to leverage these, the CDT v3.0 release has added these to the ‘C’ API for devs and some of them to the ‘C++’ API. For a list of these functions, see A-5.

Some C++ API wrappers are left out in this release as they would be immediately deprecated.

These new functions and data types are planned in the next major release.

Bug Fixes

Because of build issues, the CDT v3.0 release has removed the ability to compile CDT with ccache and sccache.

Other Release Notes

New Build Procedure

A new build process driven by CMake replaces the shell scripts previously recommended for building the software. Those who wish to build from the source code are now responsible for installing the necessary dependencies. The list of dependencies and the recommended build procedure are in the README.md file. The readme also includes instructions for efficiently running tests.

Ubuntu 18.04, 20.04, and 22.04 are the only supported build platforms. Other distributions, compilers, and platforms are known to work. Your experience may differ.

Compatibility.

DUNE
Snapshot compatibility

Node operators can use snapshots to sync nodeos more rapidly with the rest of the blockchain.

The newest snapshot version introduced with the Mandel v3.1 release, v6, is only compatible with nodeos v3.1. The older v4 snapshot is compatible with the Mandel v3.1 release, the EOSIO v2.0 release and the EOSIO v2.1 release. 

V5 snapshots are from the unsupported EOSIO v2.1 release and will NOT work with the Mandel v3.1 release unless the EOSIO v2.1 release features are disabled. 

Network Compatibility

Network compatibility refers to the ability of a node to accept blocks and transactions over the p2p connection between nodes and to respond to block requests.

This release is compatible with networks running the EOSIO v2.0.x release and networks running the EOSIO v2.1 release as long as the network has NOT enabled the EOSIO v2.1 release-specific features.

State_history_plugin Compatibility.

The Mandel v3.1 release is compatible with the block logs and state history plugin (SHiP) logs produced by the EOSIO v2.0 release, but NOT the EOSIO v2.1 release. 

The Mandel v3.1 release’s new features required changes to the state history ABI. Consumers of state history from a Mandel v3.1 nodeos instance must be prepared to handle the following changes.

A new action_trace_v1 and chain_config_v1 will be sent instead of the previous _v0 versions. Clients must be prepared to receive either the v0 or v1 variation, as they will continue to receive v0 versions from entries in the state history log before the upgrade to the Mandel v3.1 release.

State File Compatibility.

This release is NOT compatible with the state files generated by earlier releases. Please use a compatible snapshot file generated from an earlier version of nodeos to rebuild the current state file.

Upgrading from Prior Releases

Generate a snapshot of the state from nodeos. You cannot use snapshots from the EOSIO v2.1 release, but snapshots from the Mandel v3.0 or v3.1 releases as well as earlier snapshot versions will work.   

Remove the state file used by the upgrading node. If the node has been using EOSIO 2.1, operators must also remove the SHiP and block logs. SHiP and block logs can remain if the node is upgrading from the EOSIO v2.0 release.

Start nodeos with the snapshot. Afterwards, nodeos will start and stop as usual.

Deprecations & Removals

The Mandel v3.1 release removes some deprecated features from EOSIO. Among these are the history_plugin and the mongoDB_plugin, both of which can use the state_history_plugin or the trace_history_plugin as an alternative. The Mandel v3.1 release also removes WABT in favour of the more performant EOS VM. It also drops Mac support, although Mac and Windows users can still use DUNE to virtualize a Mandel blockchain environment. 

The new update deprecates cleos WAST output, and a later update will remove it.

ABI conversion APIs are deprecated.

The APIs /v1/chain/abi_bin_to_json and /v1/chain/abi_json_to_bin have been deprecated as of this release and will be fully disabled or removed in a future release. This is due to the security risk of blindly trusting these APIs, which a malicious actor could exploit to switch parameters during the conversion. 

Build Scripts Removed.

As mentioned earlier, the Mandel v3.1 release removes the build scripts from EOSIO. See README.md at the eosnetworkfoundation/mandel Github repository for instructions to build.

history_plugin removed.

The history_plugin was deprecated in 2018 as part of the EOSIO v1.2.0 release, and the Mandel v3.1 release fully removes it. More RAM-efficient solutions like the state_history_plugin and Hyperion have since replaced the history_plugin. 

This means that nodes that initialize with the option --plugin eosio::history_pluginshould instead migrate to the option --plugin eosio::trace_api_pluginor --plugin eosio::state_history_plugin

mongo_db_plugin removed

The mongo_db_plugin was deprecated as part of the EOSIO v1.8.0 release, and this release fully removes it.

Reversible block database removed

A chainbase database is no longer used to store the active set of reversible blocks during nodeos operation. The reversible blocks are still stored in the fork database upon shutdown.

Note: Node operators should remove any existing configuration for the reversible block Chainbase database from the config.ini file and any scripts, including: 

  • reversible-blocks-db-size-mb
  • reversible-blocks-db-guard-size-mb
  • fix-reversible-blocks
  • import-reversible-blocks 
  • export-reversible-blocks

Dropped support for Ubuntu 16.04, Centos, and MacOS

(Supports Ubuntu 18.04, 20.04, 22.04) (Devs should use DUNE for Windows, Mac, and any Linux distribution that supports Docker)

Ubuntu 16.04, Centos, and macOS

As mentioned earlier, the only officially supported platforms are Ubuntu 18.04, 20.04 and 22.04. Mandel has removed all others, including Ubuntu 16.04, Centos, and macOS, from binary package support and code-level changes.

Developers running the Mandel v3.1 release on a non-Ubuntu machine should consider using DUNE, which supports Windows 10 and 11, macOS, and any Linux distribution that supports Docker.

Proposed Deprecations

Deprecate the r1 curve and multi-key control for Block Producers

A future release may deprecate block producers using R1 curves for signing blocks due to lack of use.

EOSIO originally allowed block producers to register multiple keys with multiple weights as a block producer, much as multiple weighted keys can control accounts. It also allowed block producers to register keys with the k1 or r1 curve. These are different curves used in elliptical-curve cryptography. 

Official documentation specified the r1 curve used a “verifiably random” curve. Bitcoin fans widely speculate that Satoshi Nakamoto, the creator of Bitcoin, didn’t trust this “verifiably random” curve not to have a potential backdoor. Because of this mistrust and the efficiency of the secp256k1 curve, Bitcoin uses the k1 curve. 

Block producers on EOS don’t use keys on the r1 curve or multi-key block production. This open Github issue seeking feedback proposes to drop support for keys on the r1 elliptic curve and drop multi-key producer authority. 

Replace YubiHSM Support with Generic HSM Support

The EOSIO v1.7 release shipped with a tool that allows users to easily create a key on the EOSIO tool keosd, using the YubiKey hardware authentication device. This proposal points out the unnecessary dependencies and software integration hurdles that this tool comes with and proposes an alternative tool compatible with any generic hardware authentication device, including the YubiKey. 

This alternative would require a new tool to facilitate smooth integration of the two-user generic tool into the single-user keosd environment.

Appendix

A-1 New send_transaction2 Endpoint structure:

The endpoint has the following structure:

struct send_transaction2_params {

    bool return_failure_trace = true; ///< Embed transaction exceptions into the returned transaction trace

    bool retry_trx = false; ///< request transaction retry on validated transaction

    std::optional<uint16_t> retry_trx_num_blocks{}; ///< if retry_trx, report trace at specified blocks from executed or lib if not specified

    fc::variant transaction; ///< same format as send_transaction
};

A-2 Syntax for the Transaction Finality Status Endpoint

The endpoint has the following syntax:

struct get_transaction_status_params {
      string id; //transaction id to status
 };
 struct get_transaction_status_results {
    string state;
    std::optional<uint32_t> block_number;
    std::optional<chain::block_id_type> block_id;
    std::optional<fc::time_point> block_timestamp;
    std::optional<fc::time_point> expiration;
    uint32_t head_number;
    chain::block_id_type head_id;
    fc::time_point head_timestamp;
    uint32_t irreversible_number;
    chain::block_id_type irreversible_id;
    fc::time_point irreversible_timestamp;
    chain::block_id_type last_tracked_block_id;
};

A-3 Resource cost calculation

The calculation uses an exponential moving average of an account’s chain utilization, using linear extrapolation when given limited data. It multiplies the currently accumulated average by (number of blocks in the window – number of blocks since the last update) / (number of blocks in the window). 

EMA is calculated for each period in a window, such that:

EMA = Exponential moving average, 

k = Weighting multiplier, k = 2N + 1 where N = the number of periods in the time window.

pc= This period’s closing price, 

EMAp= Previous period’s EMA, with the first period’s EMA = the SMA of the time window.

The formula is:

EMA is calculated one period at a time, starting with the first period. The EMA of the first period is the same as the SMA (Simple Moving Average), which uses a typical averaging formula of:

Where n is the number of periods in a window and A is the value of each period.

A-4 GELF Reserved Fields:

The list of reserved field names is:

_id
_timestamp_ns
_log_id
_line
_file
_method_name
_thread_name
_task_name

A-5 New C and C++ API Functions for Crypto Extensions:

C API now has the functions:

void sha3( const char*, uint32_t, char*, uint32_t , int32_t)
int32_t blake2_f(uint32_t, const char*, uint32_t, const char*, uint32_t, const char*, uint32_t, const char*, uint32_t, int32_t, char* , uint32_t)
int32_t k1_recover( const char*, uint32_t, const char*, uint32_t, char*, uint32_t)
int32_t alt_bn128_add( const char*, uint32_t, const char*, uint32_t, char*, uint32_t)
int32_t alt_bn128_mul( const char*, uint32_t, const char*, uint32_t, char*, uint32_t)
int32_t alt_bn128_pair( const char*, uint32_t)
int32_t mod_exp( const char*, uint32_t, const char*, uint32_t, const char*, uint32_t, char*, uint32_t)
uint32_t get_block_num( void )

The C++ API now has the functions:

block_num_t current_block_number() - (in system.hpp)
eosio::checksum256 sha3(const char*, uint32_t) - (in crypto.hpp)
eosio::checksum256 keccak(const char*, uint32_t) - (in crypto.hpp)
void assert_sha3(const char*, uint32_t, eosio::checksum256&) - (in crypto.hpp)
void assert_keccak(const char*, uint32_t, eosio::checksum256&) - (in crypto.hpp)

原文链接/Original URL:

https://eosnetwork.com/blog/mandel-v3-1-release-features/

About the author

By user
News.EOS.WiKi Bilingual News & Info Of EOS

Recent Posts