Hyperledger链码外部服务调用

huangapple go评论79阅读模式
英文:

Hyperledger chaincode external service calls

问题

链码是否可以进行外部服务调用?例如,如果我需要使用公共API查找当前汇率或今天的温度,我该如何从链码中进行调用?

如果允许外部调用,那么每个节点提供的输出可能会不同(非确定性行为)。那么如何达成共识呢?

英文:

Is it possible to make external service calls from chaincode? For example, if I need to lookup the current exchange rate or today's temperature using a public API how can I make that call from the chaincode?

If external calls are allowed then there is a chance of each node providing a different output (non-deterministic behavior). So how will consensus be reached?

答案1

得分: 4

不同来源的两个资产更新总是有机会以不同的顺序到达两个背书者。这将创建不匹配的读/写集。如果背书策略要求所有背书者实现相同的读/写集,这可能导致两者都失败。添加读取可能因为任何数量的瞬时问题而发生更改或失败的外部数据只会加剧这个问题。

但是,无论采用何种背书策略,更改都将得到正确处理,因为只有经过背书的读/写集才会被提交。

现在,如果你决定从链码向外部数据库写入数据,那么一切都不确定了。由于同一个区块中的键冲突(fabric v1要求不能同时处理针对相同键的更新,因此必须进行流量控制),最后一刻的失败将导致事务永远不会被提交。

当发生这种情况时,外部写入应该被回滚,但是链码已经执行完毕,因此整个数据集现在已经被破坏。这是一个不可行的方案。

然而,如果有人决定冒险构建一个复杂的系统,其中链码更新外部数据,那么如果事务ID是更新的日志条目的一部分,故障可以被检测到并回滚更新。这个解决方案非常脆弱,如果你尝试它,你可能会后悔 Hyperledger链码外部服务调用

英文:

There is always the opportunity for two asset updates from different sources to hit two endorsers in a different order. That will create read/write sets that do not match. This can cause both to fail if the endorsement policy requires that all endorsers achieve the same r/w set. Adding reads of external data that can change or can fail owing to any number of momentary issues just exacerbates this issue.

But the changes will be handled correctly no matter which endorsement policy is in effect because only endorsed r/w sets get committed.

Now, if you decide to write to an external database from a chaincode, then all bets are off. A last minute failure because of key clashes in the same block (fabric v1 requires that updates targeting the same keys never be processed together and thus must be flow controlled) will cause the transaction to never get committed.

When that happens, the external writes should be rolled back, but the chaincode is long done executing and so the total dataset has now been corrupted. This is a non starter.

However, should someone decide to tempt fate and build an elaborate system where chaincode updates external data, the failure can be detected and the updates rolled back so long as the transaction ID is part of the journal entry for the update. This solution is unspeakably brittle, and if you try it then you will likely be sorry Hyperledger链码外部服务调用

答案2

得分: 2

这是要翻译的内容:

可以做到而且不会破坏Fabric。Fabric不需要是确定性的,因为RW集合在所有背书节点上都会进行检查,但不会被重放,只是在提交事务提案时检查读取副本集合是否相同。

在接收方的背书节点上,会检查读取副本,并且如果本地副本和提议的副本具有相同的版本,则事务是有效的。

在Solidity的智能合约中,事务会被重放,这就是为什么它必须是确定性的。

英文:

It is possible and doesn't break Fabric. Fabric doesn't have to be deterministic as the RW set is check on all endorsers but it's not replayed, only it's check that the READ replica set is the same when the transaction proposal is submited.

On the receivers endorser the READ replica is check and if the local and the proposed have same versions the transaction is valid.

On Solidity's smartcontracts the transaction is replayed, that's why it must be deterministic.

答案3

得分: 0

我认为调用外部API的方法并不完全邪恶。这是验证认可节点从外部源获取数据的完美方式,例如从可信的全球源获取今天的$/€汇率。如果所有认可节点从同一来源获得相同的结果,各方就不能说:“嘿,你编造了货币,你是腐败的”。

根据这份Hyperledger-Composer文档,该部分讨论了以下内容:外部API调用是否可行,如何使用、何时使用、何时避免以及优缺点等。我想强调这一部分作为答案:

由于多种原因,HTTP请求可能会得到不同的响应:

  • 不同组织的对等节点可能位于不同的数据中心、不同的国家或不同的时区。
  • 不同组织的对等节点可能无法访问HTTP服务器,这取决于公共互联网访问和防火墙限制。
  • 不同组织的对等节点可能以不同的用户身份对HTTP服务器进行身份验证,导致不同的HTTP响应。

为了在事务处理器函数中进行HTTP请求时最大限度地减少共识失败的风险,建议您使用满足以下条件的HTTP请求:

  • 安全的,即HTTP请求不会修改HTTP服务器上的任何状态。
  • 幂等的,即相同的HTTP请求可以多次执行而不会产生不同的结果。
英文:

I think calling external APIs approach is not totally evil. It's perfect way to validate endorsing peers that really data retrieved from external source. i.e getting today's $/€ rate from a trusted global source. Parties cannot say that: "Hey you made up the currency, you're corrupt", if all endorsing peers got the same result from same source.

According to this Hyperledger-Composer Documentation, the section discusses: if external-api calls are possible, how and when to use it, when to avoid it, pros and cons, etc. I want to emphasize this section as an answer:

> HTTP requests may result in different responses for multiple reasons:
>
> * Peer nodes in different organisations may run in different data
> centers, in different countries, in different time zones.
> * Peer nodes in different organisations may not have access to the HTTP server
> depending on public internet access and firewall restrictions.
> * Peer nodes in different organisations may authenticate to the HTTP server
> as different users, resulting in different HTTP responses.
>
> In order to minimize the risks of consensus failures when making HTTP requests
> from a transaction processor function, it is recommended you use make
> HTTP requests that are either:
>
> * Safe, in that the HTTP request does not modify any state on the HTTP
> server.
> * Idempotent, in that the same HTTP request can be made many
> times without different outcomes.

答案4

得分: -1

  1. 是的,我们可以进行外部 API 调用。为了方便起见,我更喜欢使用 Node SDK 而不是 Go 语言来编写链码。
  2. 通常情况下,链码在其中一个节点上执行,外部 API 调用也是如此。一旦得到结果,交易将在网络中广播。其他节点通过哈希链验证交易。因此,API 调用不会在所有验证节点上执行。
英文:
  1. Yes. We can make external API calls. for ease i prefer node sdk instead of go lang for chaincode
  2. Normally chain code is executed on one of the peers, and so is the external api call. Once the result is derived, the transaction is broadcast in the network. Other peers validate the transaction by chain of hash. So the API call is not executed on all validating peers.

huangapple
  • 本文由 发表于 2016年11月4日 18:25:17
  • 转载请务必保留本文链接:https://go.coder-hub.com/40420278.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定