为什么很多情况下无法应用智能合约

智能合约的目的之一是交易对手之间的支付交易的自动化。 我们的无线区块链支付服务可在该市场中使用。 尽管有智能合约的承诺,但是该材料的作者分析了该技术的缺点。

作为流行的区块链平台的开发人员,有时会问我,在以太坊中使用的类似的多链服务的开发计划中,是否存在智能合约的地方。 答案总是听起来像:“不,或者至少现在不行。”

图片

但是在喧闹的区块链世界中,智能合约被认为是非常酷的东西。 为什么总是没有答案? 好吧,问题在于,如果对于像比特币这样的受控比特币,我们至少知道三种实际应用的强大场景(跟踪起源历史,存储公司文档,促进金融系统的组织),那么对于效率等效的空中智能合约情况根本不存在。

这并不是人们不了解智能合约的要求。 问题在于,许多这样的想法根本不可行。 当聪明人听到“智能合约”一词时,他们倾向于自由发挥想像力。 绘制智能独立软件的头像,乘以数据浪潮,并连接到解决实际问题上。 不幸的是,关于智能合约如何工作的真实描述更加平淡无奇。

智能合约是存储在区块链上的一段代码。 它由区块链交易提供动力,可以从区块链中读取数据或向其中写入数据。 仅此而已。 或多或少。

智能合约只是在区块链上工作并与其状态交互的代码的老称。 这是什么代码? 这是Pascal,Python或PHP。 也许是Java,Fortran或C ++。 如果考虑数据库格式,则可以用在SQL的某些扩展中编写的程序形式来表示它。

从根本上讲,所有这些语言都是等效的;它们使用相同的方法来解决相同类型的问题。 当然,他们每个人都有优点和缺点。 尝试创建一个C网站或用Ruby压缩高清视频会很疯狂。 但是至少从理论上讲,如果您愿意,您可以这样做。 就便利性,性能而言,您只需要付出高昂的代价,而且很可能会损失很多头发。

智能合约的问题不仅在于过高的期望值,还在于这些期望值导致大量人将时间和金钱花在不太可能在实践中实现的想法这一事实。

实践表明,从高层管理人员了解新技术到真正了解其优势和局限的那一刻,大公司通常具有足够的资源。

在过去的九个月中,我们听取了关于使用智能合约的可能方案的大量讨论,并且碰巧我们一次又一次地回答了他们的作者,这些想法根本无法在现实生活中实现。

结果,我们确定了关于智能合约主题的三个最常见的误解。 这些想法是不正确的,不是因为技术还不够成熟,还是因为我们还没有任何工具。

相反,它们是基于对驻留在数据库中并以分散方式处理的代码的基本属性的误解。

1.与外部服务的互动


通常,您会听到有人提议使用智能合约来响应某些外部事件而更改其行为。 例如,一项农业保险政策,根据给定月份的降雨量进行支付。

根据该想法的作者的想法,该过程大致如下进行:智能合约等待特定的预定时间,从外部服务接收天气报告,并根据接收到的数据进行操作。

听起来很简单。 同时实现简单和不可能。 怎么了 因为区块链是基于共识的系统,这意味着它仅在每个网络节点在处理每个事务和每个块之后达到相同状态时才起作用。

必须完全确定在区块链上进行的所有操作,而丝毫不会出现任何差异。 一旦两个诚实节点在链的状态上占据不同的位置,整个系统就会变得无用。

现在让我提醒您,每个链结节点都独立执行智能合约。 这意味着,如果智能合约从外部来源接收到某些信息,则每个节点都会重复执行独立获取数据的过程。 但是由于源位于区块链之外,因此无法保证每个节点都会收到相同的响应。

源可能会在两个不同节点之间的请求之间的某个时间点更改其响应,或者它可能暂时不可用。 一种或另一种方式将无法达成共识,整个区块链将停止工作。

可以找到什么出路? 解决方案实际上非常简单。 您只需要用一个或多个受信方(即所谓的oracle)来代替将智能合约与外部源联系的过程,即可创建将必要数据写入链的交易。 然后,每个节点将具有相同的数据副本,并且可以在智能合约的计算中使用它们。

换句话说,不是将智能合约从外部“拉出”数据,甲骨文将把相同的数据输入到区块链中。

当涉及触发外部世界中某些事件的智能合约时,也会出现类似的问题。 例如,许多人喜欢使用银行的API进行转帐的智能合约的想法。 但是,如果每个节点独立执行链代码,那么哪个节点将负责调用API?

如果这将是任何一个节点,那么如果该特定节点有意或无意地发生故障,将会发生什么? 而且,如果将联系所有节点,我们是否可以使用API​​密码信任每个节点? 可以打几百个电话而不是打个电话吗? 更糟糕的是:如果智能合约需要确定API调用的成功,那么我们再次面临依赖外部数据的问题。

还有一个简单的出路。 代替指示智能合约访问外部API,我们可以使用受信任的服务来监视区块链的状态并响应接收到的数据执行某些操作。 例如,银行可以主动监控区块链,并进行相应于链中批准的交易的汇款。 这种方法不会给达成共识带来任何风险,因为此模型中的链条起着绝对被动的作用。

考虑了上述情况的建议解决方案后,我们可以得出一些结论。

首先,这两种方法都需要可信的第三方来管理区块链与外界之间的交互。 尽管在理论上有可能实施这种模型,但在其框架内进行的任何分散都将失去所有意义。

其次,这些示例中使用的机制是读取和写入数据库的直接示例。 提供外部信息的Oracle只需将其写入链中。 重复现实世界中区块链状态的服务无非就是从该链中读取信息。 换句话说,在这种情况下,区块链与外界之间的任何交互都归结为正常的数据库操作。

在后面的材料中,我们将更详细地揭示这一事实。

2.在链内付款


我们经常听到的另一个建议是:使用智能合约来自动执行所谓的智能债券的息票支付。 这个想法的实质是在智能合约要求的时间自动初始化付款。 这将避免手动处理付款,并确保发行人不会违约。

当然,为了使该想法可行,用于支付的资金也必须位于区块链内部。 否则,智能合约根本无法保证付款。

让我们记住,区块链只是一个数据库。 在我们的案例中,一个包含已发行债券和一些收银台的财务登记册。 因此,当我们谈论息票支付时,我们实际上是在商定的时间自动执行数据库操作。

尽管从技术角度来看,这种自动化是可行的,但是在模型的财务方面会出现困难。 如果用于票息支付的资金由债券智能合约控制,那么这些支付确实可以得到保证。 但是在这种情况下,债券发行人将无法将这些资金用于任何其他目的。 而且,从智能合约的控制中撤出资金会使保证其付款的任何保证均无效。

换句话说,对于发行人或投资者而言,明智的债券都是毫无意义的。 如果您反思这种情况,那么这样的结论将变得显而易见。

从投资者的角度来看,购买债券的本质是在存在一定可接受的违约风险的情况下获得诱人利润的能力。 对于发行人而言,发行债券的目的是为生产性但有些冒险的活动筹集资金,例如兴建新工厂。

发行人无法筹集资金,同时还要明确保证向投资者付款。 我认为,风险和获利能力之间存在的规律性不包括在区块链可以解决的任务列表中,这一事实不会让人感到惊讶。

3.需要隐藏敏感数据


如我先前所写,部署区块链时我们面临的最严峻挑战是它们提供的极高透明度。

例如,如果一组由10家银行组成的银行想要一起创建一个区块链,则该区块链中的任何双向交易都会立即对其他八位参与者可见。 尽管存在各种使这种效果成为可能的策略,但是它们都无法超越由完全控制所有参与者的可见性和访问级别的某个人管理的集中式数据库的简单性和有效性。

有人认为智能合约可以解决这个问题。 他们的推理始于每个智能合约都包含其自己的微型数据库并对其进行完全控制的事实。 该数据库中的所有读取和写入操作完全由合同代码来介导,这排除了一个合同读取另一个合同的数据时的情况。 (数据和代码之间的这种紧密联系被称为封装。它是面向对象编程的流行范例的基础)。

因此,没有智能合约可以访问其他智能联系人的数据。 但这能解决区块链中的隐私问题吗? 谈论将信息隐藏在智能合约中是否有意义? 不幸的是,答案是否定的。

是的,智能合约无法从其他合约读取数据,但是,这些数据的这些副本仍位于每个单独的网络节点中。 每个参与者都将这些数据存储在他们的内存或系统的硬盘驱动器中,该数据由其完全控制。 结果,无论何时何地,参与者都无法阻止其在自己的系统中读取信息。

在智能合约中隐藏数据的尝试在安全级别上与试图将它们隐藏在网页的HTML代码中具有可比性。 当然,普通的Web用户将不会看到此类信息,因为它不会显示在浏览器窗口中。 但是对于其公开,您只需单击按钮以显示“源代码”,该代码在所有现代浏览器中都将显示,并且数据立即在您的手掌中。

同样,在智能合约中隐藏数据的情况下,所需要做的就是更改与区块链一起使用的软件,以使其显示合约的完整状态,并且所有保密性立即消失。

任何中产阶级的程序员将在不超过一个小时的时间内完成这项任务。

智能合约的目的是什么?


综上所述,出现了一个合理的问题:智能合约通常可以在哪里找到应用程序? 但是为了回答这个问题,我们需要在精神上回到区块链的基本概念。 简而言之,区块链允许一群互不信任的人直接,安全,直接地与数据库一起工作,而无需求助于某个主要管理员。

区块链使您可以放弃使用数据的中介,这可以大大简化并降低成本。

要对任何数据库进行更改,必须执行一个所谓的事务,该事务包含数据库中的一组更改,这些更改将成功应用或全部拒绝。 例如,当爱丽丝为鲍勃付款时,财务登记处的情况。 付款以交易的形式呈现:a)检查Alice帐户中是否有足够的资金,b)从Alice的帐户中扣除指示的金额,c)将相同的金额添加到Bob的帐户中。

在常规的集中式数据库中,这些事务由单个受信任的管理器创建。 相反,在公共的区块链类型数据库中,任何区块链用户都可以创建交易。 并且,由于这些用户之间没有绝对的信任关系,因此数据库中应该存在一些规则,这些规则对事务的执行施加了限制。

例如,在其所有节点都处于相同位置的财务注册中心中,每笔交易的参数都不应导致违反资金的一般余额。 否则,参与者将能够自由分配他们想要的钱。

有很多方法可以遵守这些规则,但是目前在比特币和以太坊的影响下占主导地位的是两种范例。 比特币方法可以用另一种方式称为“交易限制”,它从以下角度评估每个交易:a)使用该交易删除的数据库中的记录,以及b)创建的记录。

该规则在财务注册表中使用:已删除记录中的资金总额不应与已创建记录中的资金总额相冲突。 (记录中的更改被认为是该记录的删除,并带有必要的值对其进行重新创建)。

起源于以太坊的第二个范例是智能合约。 根据它,合同数据中的所有更改均应由其代码执行。 (在传统数据库的情况下,我们可以假设这是一个强制性的存储过程)为了修改合同的数据,区块链的用户将请求发送至其代码,该代码确定是否应满足该请求以及应如何完成该请求。

根据以上示例,用于财务注册中心的智能合约执行与集中式数据库的管理员相同的任务:检查是否有足够数量的资金,从一个帐户中减去这些资金,然后再添加到另一个帐户中。

两种范例都有效地工作,并且每种都有其优缺点。 简而言之,限制比特币类型的交易可让您获得更好的同时访问和性能指标,而智能以太坊类型的合约则具有更大的灵活性。

因此,回到智能合约的意义是什么:当无法使用交易限制来实现区块链案例时,就需要使用智能合约。

但是,即使已经决定了使用智能合约的标准,但我仍然发现很难列举至少一种适用于封闭式区块链的方案,而传统的比特币方法实际上是不适用的。

我所知道的所有真正有趣的区块链项目都可以使用比特币方法来实施,在该框架内可以实现访问权与数据存储的分离,以及资产的创建,资产的移动,存放,交换和破坏的实现。 即便如此,新用例仍会定期出现,如果其中一些确实需要智能合约的功能,我也不会感到惊讶。 或至少是比特币范式的扩展。

无论如何,关键的规则是要记住,智能合约只是限制数据库中交易执行的一种方法。

, , . - . , .

图片

Source: https://habr.com/ru/post/zh-CN405511/


All Articles