Cointime

扫码下载App
iOS & Android

The Graph Indexer线上会议 #184

TL;DR: The Graph 的TAP迁移截止日期是2024年12月3日,大约34%的索引器已经升级,占查询量的81.6%。问答讨论的重点是TAP的配置设置,特别是关于RAV(收据聚合凭证)请求和管理非聚合费用,建议从默认值开始并根据查询量进行调整。

大家好,欢迎阅览 Indexer Office Hours 会议纪要,第 184 场!

视频链接:https://youtu.be/w0LZkVJemPY


观看 Persistence Labs 首席运营官 Jeroen Develter 的 GRTiQ 播客。Jeroen 的 web3 之旅始于传统金融、咨询领域,并跃入了加密货币和区块链的世界。

重要存储库的最新更新

  • Geth 新版本 v1.4.12 :
  • 日期:2024-11-19 13:53:28 UTC
  • 该版本删除了已弃用的个人 RPC 命名空间和 –unlock 命令,这表明密钥管理发生了重大变化。它还包括优化、数据库改进和各种错误修复,以及跟踪器配置的重大更改。
  • 紧急指标:黄色
  • 紧急原因:密钥管理更改需要用户进行调整。
  • Reth 新版本 v1.1.2
  • 日期:2024-11-19 16:27:10 UTC
  • 此版本包括性能改进和错误修复,并为全新硬分叉做好了显著的准备。这些更改专门优化了有效负载作业获取并解决了待处理事务排序,这使得 OP-reth 用户及时更新至关重要。
  • 紧急指标:红
  • 紧急原因:OP-reth 用户的硬分叉准备。
  • sfeth/fireeth:新版本 v2.8.0 :
  • 日期:2024-11-14 14:55:01 UTC
  • CombinedFilter 中集成了 nil 安全检查,增强了事务处理过程中的稳定性。此外,对 substreams 和 dmetering 的更新包括对计量功能的改进。
  • 紧急指标:黄色
  • 紧急原因:提高稳定性,并非立即构成威胁。
  • Avalanche:新版本 v1.11.13 :
  • 日期:2024-11-18 22:24:03 UTC
  • 此版本为平台引入了新的 API,并修复了 RPCChainVM 指标初始化和兼容性改进。建议 Operator 更新到最新的插件版本,以增强兼容性和稳定性。
  • 紧急指标:黄色
  • 紧急原因:重要的修复和新功能需要及时关注。
  • 索引器服务和代理(TS):新版本v0.21.8:
  • 日期:2024-11-18 19:23:13 UTC
  • 此版本包括一些小更新,通过淡化子图高度冲突消息来改进用户界面,并修复了索引代理中的轮询间隔参数。未发现影响系统性能或安全性的关键更改。
  • 紧急指标:绿
  • 紧急原因:低影响的更改,没有关键问题。
  • 索引器服务和点击代理(RS):新版本索引器-tap-agent-v1.7.3:
  • 日期:2024-11-13 19:04:13 UTC
  • 版本 1.7.3 通过删除托管适配器检查解决了一个错误,这可能会影响交易处理。所有操作员都应查看此更改以确保无缝功能。
  • 紧急指标:黄色
  • 紧急原因:重要修复,不是关键,但建议尽快更新。

协议重要变更的最新更新

  • 在 The Graph 中增强仲裁:工作组启动、仲裁委员会扩展和流程更新
  • 新的仲裁工作组将暂时承担仲裁分析师的职责,直到新的分析师入职。
  • 仲裁委员会的扩大加强了 The Graph 在仲裁中维护高标准的承诺。
  • 仲裁程序正在积极审查中,以确定需要改进的地方。
  • 请参阅论坛帖子以获取常见问题解答和参考资料。
  • 有关争议 #GDR-19 的信息请求
  • 此争议与 GDR-18 有关,因为同一索引器重复了之前导致被罚没的行为。
  • 常规:对非本地链使用 hardhat-secure-accounts #1070 (open)
  • 常规:Bump Ignition 版本到 0.15.7 #1069 (Open)
  • 修复:为部署脚本添加了缺少的参数,并将 SubgraphService 的运行次数减少到 50 次 #1062(Open)

今天的讨论是 TAP 迁移问答,来自 GraphOps 的 Ana 和来自 Semiotic Labs 的 Gustavo。TAP 是用于查询 The Graph 的新小额支付系统。

🚨 索引器需要在2024年12月3日前迁移到TAP。

该会议以 Ana 的 IOH TAP 迁移问答说明为指导,这些说明已与讨论中的一些背景信息一起复制到本节中。评论经过轻微编辑

Ana |GraphOps:让我们从什么是 TAP 开始?

TAP (Timeline Aggregation Protocol) 概述:

  • 取代旧的 Scalar 支付系统。
  • 具有高效小额支付、减少链上交易和索引器对收据的控制等关键功能。
  • 通过允许索引器接受来自多个网关的查询来启用分散式网关。

索引器需要做什么?

  • 更新索引器堆栈以运行 indexer-agent(版本 0.21.4 或更高版本),替换 indexer-service 以运行 Rust 版本,并添加新组件 indexer-tap-agent。
  • Indexer repo (indexer-agent)
  • Indexer-rs 代码库(indexer-service 和 indexer-tap-agent)
  • 资源:
  • 如果使用 Kubernetes,请使用 launchpad-charts/graph-network-indexer
  • 如果使用 Docker Compose,请使用 StakeSquid 堆栈
  • TAP 迁移指南

Mickey |The Graph |E&N:如果索引器错过了截止日期怎么办?网关不会将任何新查询路由到它们,直到它们升级或...?

  • Gustavo |Semiotic Labs:网关目前提供 Scalar 和 TAP 的收据。一旦我们到达截止日期,网关将仅支持 TAP 收据。如果您的版本低于 1.0,则不会再收到查询。
  • Ana:谢谢,这很有意义。因此,如果要继续获取查询,则需要迁移。

Mickey |The Graph |E&N:有什么方法可以判断有多少百分比的索引器已经转移到 indexer-rs/tap 了?

  • Ana:判断索引器是否已迁移到 TAP 的一种方法是,他们在 GraphSeer 中的索引器配置文件上是否有标有 TAP READY 的徽章。
  • Gustavo:在 Semiotic,我们正在密切跟踪这个数字,检查索引器是否正在运行高于 1.0 的版本。在我们跟踪的 88 个索引器中,有 30 个运行的索引器为 1.0 或更高版本,约占索引器的 34%。
  • 我们还在跟踪每个查询在上个月提供的查询数量,因此我们目前有 81.6% 的查询通过 TAP 运行。
  • Ana:我认为您所说的是查询量最高的索引器已经升级。
  • Gustavo:是的。在排名前 10 的索引器中,有 9 个已升级。实际上,在前 14 个索引器中,有 13 个已经升级。

Mickey |The Graph |E&N:我的印象是,很多索引器在升级时遇到了问题 - 这种印象正确吗,如果是这样,那么 12 月 3 日的最后期限是否现实,以便让每个人都在那之前升级?(没有阴影,只是好奇这是否足够稳定)

  • Gustavo:我认为我们正按计划 [迁移] 大多数查询。在 12 月 3 日截止日期之前迁移 100% 的索引器有点困难,但我认为我们可以轻松达到 95%。我们在这里为您提供支持,以便我们可以尝试达到 100%。

Mickey |The Graph |E&N: 为什么是88个[索引器]?这些只是实际服务于查询的吗?

  • Gustavo:我们使用服务质量 (QoS) 子图来检查所有活跃的索引器,所以基本上,如果它们在上个月服务了一个查询,那么它们就会出现在 88 个列表中。我们主要关心查询,如果提供查询的索引器使用的是最新版本,我们对此感到满意。

paka |E&N :我也有信心将大部分查询流量带到 TAP。

Mickey |The Graph |E&N:好的,明白了!好的策略。

Mickey |The Graph |E&N:您是否会单独联系那些提供查询但尚未升级的落后者?

  • Gustavo:我们正在联系我们接触的索引器。我们有一个列表,我们正在联系每个列表,从最大的开始。目前,尚未升级的两个最大的是升级索引器[Edge & Node]和Pinax。我们正在与Edge和Node紧密合作,以便他们可以支持升级到1.0以上的版本。只要我们与该索引器有联系,我们就会逐个从服务量最大的查询到服务量最少的查询。

Ana:欢迎索引器标记任何已迁移的索引器以寻求帮助。如果您有任何疑问,请随时与我们联系。

Gustavo | Semiotic Labs: 如果有人有任何问题,我将在The Graph Discord中📁︱indexers和📁︱indexers -software频道回答。

  • 未聚合的费用和 RAV 请求:
  • 问题:索引者可能会看到他们的未聚合费用趋于稳定,尤其是在 rav_request_trigger_value 设置得太低时。
  • 解释:rav_request_trigger_value确定索引器何时向发件人请求收据聚合凭证 (RAV)(您可以将发件人视为网关)。如果此值太低,则可能无法足够频繁地满足触发器,从而导致费用累积而未汇总。
  • 方案:更新您的rav_request_trigger_value,计算公式为 max_amount_willing_to_lose_grt / trigger_value_divisor。

Ana:有一个仪表板; 我把它放在这儿。在未聚合面板中,您可以看到触发器值。在我的情况下,RAV 触发器值为 3。其工作方式是,当收到新收据时,其值将添加到未聚合费用中,并且系统会不断检查未聚合费用总额是否超过触发值。

当满足触发条件时,通过检查时间戳缓冲区来创建 RAV 请求,以确定将收据视为回执的时间回溯时间,并且它将根据 RAV 请求回执限制限制回执的数量。

如果我们快速查看配置,这里有几件事很重要:

  • max_amount_willing_to_lose_GRT
  • trigger_value_divisor

这两个决定 trigger 值。

  • timestamp_buffer_secs,即考虑收据的时间
  • max_receipts_per_request,因此 RAV 最多可以包含 10000 个收据

如果任何收据无效,则它们将单独存储在索引器元数据数据库的 Scaler TAP receipts invalid 表中。当 max_receipt_value_GRT 高于此值时,收据无效。

配置:maximal-config-example-toml

Gustavo:我只想谈谈这里发生了什么,以及为什么我们有很多配置。对于大多数索引器来说,这些配置不会成为问题,因为它们没有大量的查询量。

如果每秒的分配太多或查询太多,则可能会变得有点困难,这就是您需要更新和配置这些内容的原因。通常我建议您先尝试默认值,然后看看。当前默认值为:

  • max_amount_willing_to_lose_GRT = 20
  • trigger_value_divisor = 10
  • 这意味着,每次您尚未汇总的收据总额(也称为未汇总费用)达到 2 GRT 时,我们都会尝试汇总。但是,如果该值始终大于 2,则需要更改这些值。
  • 尽量将max_amount_willing_to_lose_GRT保持在较低水平。但是,如果 RAV 请求失败,并且你当时收到了很多收据,因为你是一个大型索引器,那么你会很快阻止发件人。
  • timestamp_buffer_secs = 60
  • request_timeout_secs = 5
  • max_receipts_per_request = 10000

前 15-20 个索引器需要更新这些值。

Pierre | Chain-Insights.io:我的理想价值观是什么?Default 对我仍然有好处?我似乎没有 RAV 请求。

Gustavo:让我检查一下......触发值 Total Unaggregated 费用。所以,首先有一些更新。您使用的是哪个版本?

Pierre:最新版本。

Gustavo:通常,当您到达触发器 RAV 时,它应该尝试创建一个 RAV 请求。如果这没有发生,我们需要进行调查。

Pierre | Chain-Insights.io:对我来说不:

tap:max_amount_willing_to_lose_grt: 20tap.rav_request:trigger_value_divisor: 2timestamp_buffer_secs: 60request_timeout_secs: 5max_receipts_per_request: 10000

Gustavo:所以你的触发值大约是 10,对吗?

Pierre 发帖说:是的,20 / 2

Gustavo:因此,只有在达到 10 GRT 或给定分配的收据达到 10000 个收据时,您才会触发 RAV 请求。由于您的查询量,我建议 0.1 左右,或者:

max_amount_willing_to_lose_grt: 1trigger_value_divisor: 10max_receipts_per_request: 1000

Pierre 发帖说:好的,谢谢。

Gustavo:如果每秒没有那么多查询,则需要有更多的 RAV 请求或具有更大的触发值。

这完全取决于您打开的分配数量和每秒接收的查询数量,以及每个分配每秒的查询数量和您拥有的任何突增。

在 TAP 中,在某个时间点聚合后,包含该时间点之前时间戳的收据将不起作用。它们被认为是无效的,所以这就是我们有这个缓冲区的原因。我们只接受 60 秒后的收据。这是因为在不同计算机之间同步 clocks 很困难。网关向您发送收据并定义时间戳,它可以在您的时钟之前或之后 5 秒。

我们将默认值设置为介于两者之间的某个位置,即每秒有 1-2 个查询,每 15 分钟会收到 1 个 RAV 请求。但是,如果您的内存少于此数量,则可能需要更新到更低的max_amount_willing_to_lose_grt。如果超过此数量,则可能需要更新到更多。

Gemma |LunaNova:这些值是按分配还是跨所有分配?

calinah |GraphOps:每个分配

Pierre | Chain-Insights.io:更新到以下版本后:

calinah |GraphOps:很好,您的接收率提高了。

Gustavo:是的,这很好。因此您希望为控制面板做的是,未聚合的费用应始终保持在 0.1,因此每次您有 RAV 请求时,它都会下降一点,然后在 15 分钟后,您有足够的收据来触发另一个 RAV 请求。

Josh Kauffman |StreamingFast.io:有人可以分享他们为这些价值观设定的内容吗?

Marc-André |Ellipfra:作为参考,我使用这些值进行竞选。我不是特别推荐它们,因为它们或多或少是随机设置的。max_willing_to_lose 非常高,以避免过于频繁地拒绝网关,我打算在某个时候降低它:

max_amount_willing_to_lose_grt = "1000.0"[tap.rav_request]timestamp_buffer_secs = 30trigger_value_divisor = 50request_timeout_secs = 20max_receipts_per_request = 2000

  • 发件人拒绝问题:
  • 发件人未在 tap.sender_aggregator_endpoints 中列出。
  • 发件人的托管余额不足以支付未付费用。
  • 未汇总费用超过max_fee_per_sender限制。
  • 问题:索引器可能会遇到发件人被拒绝的情况,从而导致查询处理和收入中断。
  • 拒绝原因:发件人被拒绝的三个主要原因:
  • 解决方案:每个拒绝原因的具体解决方案:
  • 验证 发件人是否在 tap.sender_aggregator_endpoints 部分中配置正确。
  • 调查托管资金的潜在问题并确保足够的余额。
  • 如果未汇总费用经常达到限制,请查看并可能调整 max_amount_willing_to_lose_grt 设置。
  • 注意:索引器 TAP 代理将始终以以下名称开头:

2024-11-13T08:41:31.200776Z ERROR indexer_tap_agent::agent::sender_accounts_manager: There was an error while starting the sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490, denying it. Error: No sender_aggregator_endpoints found for sender 0xDD6a6f76eb36B873C1C184e8b9b9e762FE216490at tap-agent/src/agent/sender_accounts_manager.rs:311in ractor::actor::Actor with id: "0.0"

对于未在 tap.sender_aggregator_endpoints 中或通过 env vars 以 INDEXER_TAP__SENDER_AGGREGATOR_ENDPOINTS__<address 格式配置的任何发件人>

  • indexer-agent 上的 collect-receipt-endpoint 错误:

{"level":40,"time":1731239677641,"pid":1,"hostname":"graph-network-indexer-agent-0","name":"IndexerAgent","msg":"The option '--collect-receipts-endpoint' is deprecated. Please use the option '--gateway-endpoint' to inform the Gateway base URL."}

Gustavo:您想要拒绝发件人的原因是发件人没有向您付款,因此他们没有足够的托管,或者他们询问您的金额达到了您愿意损失的金额。可能发生的另一件事是,我们为此使用无效收据,因此,如果您拥有的无效收据数量是您愿意丢失的最大数量,您将因此阻止发件人。

max_receipt_value_grt的快速更新是,这仅适用于该服务。要使 TAP 成为最低信任,这些必须是小额支付,因此一旦网关向您发送收据,这是他们将接受的最大收据值,但不会被视为无效收据。

无效收据是指您收到、提供查询,然后发现收据无效的收据。

Ana:对于无效收据,如果任何条件发生变化,它们是否会生效,或者一旦收据被标记为无效,就不再重试了?

Gustavo:没有重试。该表仅用于日志记录,因此您可以访问数据库并查看发生了什么以及收据失败的原因。

Ana:这是有道理的。此外,在 TAP 控制面板上,您可以查看发件人是否已被阻止。

  • RAV 请求错误:
  • 问题:RAV 请求期间的错误可能会中断聚合过程。
  • 错误示例:看起来 RAV 请求没有有效的收据...您可以通过增加 rav_request_trigger_value 来解决此问题。
  • 解释:此错误表明 rav_request_trigger_value 不足阻止收据包含在 RAV 请求中。
  • 溶液:错误消息中提供了解决方案 – 增加rav_request_trigger_value。
  • 软件版本:对 indexer-agent、indexer-service 和 tap-agent 使用所需的软件版本。
  • 配置文件演练:
  • 共享配置:indexer-service 和 tap-agent 共享一个通用的 TOML 配置文件。
  • 区块链地址和终端节点:
  • 重要:使用正确的合约地址、网关终端节点和链 ID。
  • 日志级别配置:要为适当的日志记录设置 RUST_LOG 环境变量,请使用 RUST_LOG=indexer_tap_agent=debug,info。
  • 指标和 Grafana 仪表板:
  • 指标终端节点:所有组件都公开了 Prometheus 的端口 7300 上的指标。
  • Grafana 仪表板:indexer-rs/docs/dashboard.json

Pierre | Chain-Insights.io:现在,直到 12 月 3 日,只有一个发件人处于活动状态?

# collect-receipts-endpoint: "<https://gateway-arbitrum.network.thegraph.com/collect-receipts>" DEPRECATEDgateway-endpoint: "<https://gateway-arbitrum.network.thegraph.com>"

  • Ana:据我所知,这是正确的,所以只有边缘和节点发送器是活跃的,每个人都在使用。GraphOps 希望在 12 月底到 1 月初将一些索引器加入到我们的网关。

Pierre:这好吗,还是我应该恢复以激活 collect-receipt-endpoint ?

  • Ana:使用 gateway-endpoint 很好。基本上,您唯一需要知道的是,您可以选择使用哪个 CLI 标志,但无论如何您都会看到相同的错误,这是一个令人困惑的错误,因此您不必在此处执行任何操作。

Ana:一些已经迁移的索引器对他们发现的想要分享的内容有什么评论吗?

  • Marc-André |Ellipfra:设置和监控仪表板至关重要。它在每个版本中都变得更加稳定,但你永远不知道。

Gustavo:如果你有任何功能请求或关于如何更好地配置它的想法,请随时在 indexer-rs repo 中提出问题。

我们很乐意查看每个问题和功能请求,以便我们可以使系统更好,技术更稳定,并希望达到更好的水平。感谢您抽出时间详细讨论 TAP。

#区块链数据索引 #web3数据分析 #TheGraph

评论

所有评论

推荐阅读

  • 法官再次驳回马斯克高额薪酬计划 特斯拉:上诉

    美国特拉华州法官再次驳回马斯克在特斯拉的高额薪酬计划,特斯拉官方社交媒体对此回应称,法院的判决是错误的,我们要上诉。这一裁决如果没有被推翻,就意味着是法官和原告律师在管理特拉华州的公司,而非它们的合法所有者——股东。

  • OpenAI回应被马斯克起诉:申请重复且依然毫无根据

    近日马斯克要求美国一法院阻止美国开放人工智能研究中心 OpenAI 非法转型为营利性企业。OpenAI 的一位发言人表示,马斯克的申请重复,且依然毫无根据。 今年 2 月,马斯克提起诉讼,称其在为 OpenAI 的创立提供资金等支持时,与该公司两名联合创始人曾有协议,OpenAI 应为非营利组织,但 OpenAI 违背了创始目标和使命,转而追求利润。6 月,马斯克撤回这一诉讼,8 月份又重新起诉。今年 11 月,马斯克对 OpenAI 提起的诉讼再度升级,指控 OpenAI 试图垄断生成式人工智能市场。

  • 国际刑警组织:警惕一种涉及稳定币的新兴加密货币欺诈行为

    国际刑警组织金融犯罪行动创纪录逮捕 5,500 人,缴获价值超过 4 亿美元的赃物。在行动期间发布了紫色通告,国际刑警组织警告各国警惕一种涉及稳定币的新兴加密货币欺诈行为。成员国被告知“USDT 代币批准骗局”,该骗局允许欺诈者访问和控制受害者的加密货币钱包。该两步方法首先使用浪漫诱饵技术引诱受害者,指示他们通过合法平台购买流行的 Tether 稳定币(USDT 代币)。一旦骗子赢得了受害者的信任,就会向受害者提供钓鱼链接,声称允许他们设置投资账户。实际上,通过点击,他们授权骗子完全访问,然后他们可以在受害者不知情的情况下将资金从钱包中转出。

  • 马斯克称SpaceX市值可能突破万亿美元

    有网友在社交媒体平台X发帖称,世界上有9家市值超万亿美元的公司,其中8家是美国公司。 对此,马斯克回复称,SpaceX有一天可能会成为它们中的一员。

  • 韩国再次推迟征收加密货币税,至2027年

    在今日的新闻发布会上,韩国最大在野党共同民主党(Democratic Party of Korea)院内领袖朴赞大(Park Chan-dae)宣布,放弃在 2025 年实施加密货币利得税的计划,同意再推迟两年至 2027 年。“推迟加密货币利得税”的提案由韩国政府和执政党国民力量党(People Power Party)提出,共同民主党此前称,推迟征税是执政党的政治伎俩。 最初,韩国计划对加密货币收益征收 20% 税款(22% 为地方税),原定于 2022 年 1 月 1 日生效。由于投资者和行业的强烈反对,该计划已两次推迟至 2025 年 1 月 1 日。今日新闻发布会后,将该税征收再次推迟至 2027 年。执政党国民力量党(People Power Party)还提出,“加密利得税宽限期 2 年仍不足够,应当放宽至 2028 年征收,对加密货币快速征税不可取,投资者可能会因此离开市场。国民力量党希望将实施时间推迟到 2028 年,以兑现在选举期间的承诺。”

  • 社区反馈链上AI代理Spectral交互合约遭黑客攻击

    12月1日消息,据 X 用户@RuslanMoody 发文提醒:“请勿与链上 AI 代理 Spectral 网站交互,其交互合约已遭黑客攻击。注:这不适用于流动性已在 Uniswap 上锁定的代币。” 另据 X 用户@0xYong_W 表示,Spectral 内盘已被别人“掏池子”。

  • 日本金融厅建议放宽信托银行发行稳定币的准备金要求,并实施旅行规则

    日本金融厅(FSA)近日向金融系统委员会支付服务工作组提出了一些有关加密货币和稳定币的想法,其中提到不愿允许信托银行以外的银行发行稳定币。而对于信托银行发行的稳定币,金融厅希望放宽目前要求所有资产必须以银行活期存款形式持有的准备金要求。但是,金融厅还希望实施旅行规则,要求信托银行发行的稳定币转账必须进行 KYC。 日本于 2022 年通过了稳定币立法,支持银行、持牌汇款公司和信托公司发行稳定币。作为其工作组演示的一部分,金融厅区分了在许可区块链上发行的稳定币和在公共区块链上发行的稳定币。它对这三种稳定币都存在于许可链上感到满意,但对允许持牌存款机构在非许可链上发行稳定币持谨慎态度。

  • 安全机构:Clipper遭攻击损失超50万美元,650万美元资金存在风险

    安全机构 fuzzland 联合创始人shoucccc 于 X 发文表示:“DEX Clipper 因 API 漏洞(如私钥泄露)遭到黑客攻击。目前损失超过 50 万美元,650 万美元资金面临风险,请用户立即提款。”

  • 日本金融厅提议为非交易所加密中介机构制定轻量级立法

    日本正在考虑为非加密货币交易所的加密货币中介机构制定新的轻量级立法。近期,日本金融厅(FSA)向金融系统委员会支付服务工作组提出了自己的想法。 日本于 2017 年为加密资产交易服务提供商(CAESP)引入了立法,涵盖了加密货币的买卖、充当经纪人、管理与这些服务相关的资金或提供托管。然而,许多不经营加密货币交易所的所谓 introducer 并不认为自身是 CAESP。 因此,金融厅正在考虑要求他们注册为中介的提案。introducer 有义务向用户提供信息,将受到广告限制,如果出现问题,可能会承担损害赔偿责任。 金融厅还考虑了如何处理损害赔偿。当前对不属于较大集团的其他金融服务中介机构的规定要求提供保证金以支付潜在损害赔偿。如果中介机构隶属于加密货币交易所,则损害赔偿可能由交易所承担。

  • 欧盟报告认可无需许可区块链在传统金融中的潜力

    欧盟近日发布了一份报告,探讨了传统金融(TradFi)中无需许可区块链的潜力。报告认为,无需许可的区块链至少应被视为传统金融和金融市场基础设施的选择,但需谨慎采用。 报告认为,此类区块链可以比私有区块链更中立,从而鼓励竞争。公共区块链实现的不受限制的访问与正在激增的孤立的许可区块链形成鲜明对比。虽然公共区块链有缺点,但有许多众所周知的解决方法可以解决它们的挑战,特别是通过在智能合约级别添加权限。 报告称,无需许可的区块链可以为 L2 区块链(包括受监管的区块链)提供互操作性层。当智能合约位于单个链上时,它们能够组合成更复杂的功能。 同时,报告也提到了公共区块链的缺点,例如可扩展性、隐私性、终结性和治理。它深入研究了每个主题,以及有争议的 MEV 问题。