基于以太坊的智能合约可能会变得非常耗时,因为以太坊的编程语言Solidity有点奇怪且有限。这就是为什么用Solidity编写的大多数智能合约都很简单,而业务逻辑是在外部实现的。
Solidity成为如此受欢迎的现象,特别是因为它让人们相信他们可以编码以太坊。毕竟,智能合约并不复杂(考虑到平台限制,它不会太复杂)......但是,这与一个远非明显的语言结构相结合(你是否知道Solidity有指针,甚至更糟糕的是,指针运算?),以及一百万加一种方法搞砸了。
整个智能合约开始非常直接:
由于Solidity本身无法调用外部数据(是的!区块链系统之外的),作为开发商,您需要离开以太坊区块链以获得ETH兑换美元汇率。 oracle是查找和验证此信息的代理,Oraclize是Solidity开发人员最常用的oracle,开发很直接:
总结:
-
我们有287行Solidity代码通过编译器 - CHECK
-
我们花了很多很多时间用Truffle,Remix等进行测试 - CHECK
-
我们有一个日期解决方案 - CHECK
-
我们将ETH兑换成美元汇率 - CHECK
-
我们花了0.001923 ETH gas - CHECK
-
我们有一个智能合约,每月15日支付 - WAIT
合同无法在每个月的15日自行调用。我们需要另一个外部区块链解决方案,必须确保每15天调用一次合同......这一切都没有让我开心。这就是为什么我决定在Solidity中找到一种更聪明的方式来编写智能合约。
介绍在Solidity中编写智能合约的更智能方法
使用Solidity实现实际业务逻辑非常耗时,有时甚至是不可能。我相信,如果在智能合约中实施更多真实的业务逻辑,那么我们都将充分挖掘以太坊作为加密平台的潜力。
我喜欢NodeJS和JavaScript。每当我写出复杂的Solidity代码时,我都会问自己“为什么这么复杂?在JavaScript中它会很容易......“
例如,找出距离下一个月的15日之前还有多少天:
或者计算信任成员资格的持续时间,然后查询Kraken关于当前ETH兑换美元汇率的信息,最后根据会员资格的持续时间计算信托的支付价值:
差异从构造函数开始。 在构造函数内部,我们将强制合同在一个月的下一个15日回调。 因此,一旦我们部署它,它将自动调用自己。 不需要外部调用。 您可以将Ether发送给信任,将成员添加到信任(外部)。 但是信任将自己执行其业务逻辑:
在函数DaysUntilNext15th中,您使用字符串嵌入NodeJS代码。 然后调用usingCaptainJS的Run方法,使用唯一的Id传输代码以识别您的回调并通知NodeJS容器加载模块时刻。
当这个JavaScript代码在NodeJS容器内执行时,#scriptIt oracle将在没有错误的情况下调用CaptainsResult函数。 代码流的其余部分是:
-
如果今天是15日,那么调用function Payout
-
否则在下个月的15号召回这份合同,function CallbackOn15th
通过调用RingShipsBell调用回调请求,这导致函数RingRing的#ScriptIt回调。
总结:
-
我们有82行Solidity代码(包括NodeJS代码)通过编译器--CHECK
-
我们花了一些时间在本地测试NodeJS代码,然后将其嵌入到Solidity中,并使用Truffle,Remix等进行一些简短的测试。 - CHECK
-
我们有一个日期解决方案 - CHECK
-
我们将ETH兑换成美元汇率 - CHECK
-
我们花了0.001462 ETH燃气费 - CHECK
-
我们有一个智能合同,每个月的15号支付一些钱 - CHECK
本文转载公众号:区块链研究实验室(bc-tech-lab)