智能合约实例（智能合约模型）

智能合约是什么？

智能合约（Smart Contract），是一段部署在区块链上的代码，一旦某个事件触发合约中的条款，代码就会自动执行。用人话来讲就是：智能合约是一份基于密码学这种高科技上面的数字化合同，与传统的纸质合同的差异就是： 自动售货机相当于智能合约，售货员相当于纸质合同。

举个简单的例子你就明白了：

假设甲向乙借了一大笔钱，虽然打了白纸黑字的借条。但是到期后，甲以各种理由拒绝还款，此时乙想要拿回借款只能起诉。智能合约就能解决这种问题，如果甲乙双方在借款前把借款金额、还款时间、对方绑定银行卡信息等打包进合约中。到了约定还款日，借款会自动划到乙的账户里，即使甲不想还也没办法。

来源：千氪财经

用Go来做以太坊开发④智能合约

在这个章节中我们会介绍如何用Go来编译，部署，写入和读取智能合约。

与智能合约交互，我们要先生成相应智能合约的应用二进制接口ABI(application binary interface)，并把ABI编译成我们可以在Go应用中调用的格式。

第一步是安装 Solidity编译器 ( solc ).

Solc 在Ubuntu上有snapcraft包。

Solc在macOS上有Homebrew的包。

其他的平台或者从源码编译的教程请查阅官方solidity文档 install guide .

我们还得安装一个叫 abigen 的工具，来从solidity智能合约生成ABI。

假设您已经在计算机上设置了Go，只需运行以下命令即可安装 abigen 工具。

我们将创建一个简单的智能合约来测试。 学习更复杂的智能合约，或者智能合约的开发的内容则超出了本书的范围。 我强烈建议您查看 truffle framework 来学习开发和测试智能合约。

这里只是一个简单的合约，就是一个键/值存储，只有一个外部方法来设置任何人的键/值对。 我们还在设置值后添加了要发出的事件。

虽然这个智能合约很简单，但它将适用于这个例子。

现在我们可以从一个solidity文件生成ABI。

它会将其写入名为“Store_sol_Store.abi”的文件中

现在让我们用 abigen 将ABI转换为我们可以导入的Go文件。 这个新文件将包含我们可以用来与Go应用程序中的智能合约进行交互的所有可用方法。

为了从Go部署智能合约，我们还需要将solidity智能合约编译为EVM字节码。 EVM字节码将在事务的数据字段中发送。 在Go文件上生成部署方法需要bin文件。

现在我们编译Go合约文件，其中包括deploy方法，因为我们包含了bin文件。

在接下来的课程中，我们将学习如何部署智能合约，然后与之交互。

Commands

Store.sol

solc version used for these examples

如果你还没看之前的章节，请先学习 编译智能合约的章节 因为这节内容，需要先了解如何将智能合约编译为Go文件。

假设你已经导入从 abigen 生成的新创建的Go包文件，并设置ethclient，加载您的私钥，下一步是创建一个有配置密匙的交易发送器(tansactor)。 首先从go-ethereum导入 accounts/abi/bind 包，然后调用传入私钥的 NewKeyedTransactor 。 然后设置通常的属性，如nonce，燃气价格，燃气上线限制和ETH值。

如果你还记得上个章节的内容, 我们创建了一个非常简单的“Store”合约，用于设置和存储键/值对。 生成的Go合约文件提供了部署方法。 部署方法名称始终以单词 Deploy 开头，后跟合约名称，在本例中为 Store 。

deploy函数接受有密匙的事务处理器，ethclient，以及智能合约构造函数可能接受的任何输入参数。我们测试的智能合约接受一个版本号的字符串参数。 此函数将返回新部署的合约地址，事务对象，我们可以交互的合约实例，还有错误（如果有）。

就这么简单：）你可以用事务哈希来在Etherscan上查询合约的部署状态:

Commands

Store.sol

contract_deploy.go

solc version used for these examples

这写章节需要了解如何将智能合约的ABI编译成Go的合约文件。如果你还没看， 前先读 上一个章节 。

一旦使用 abigen 工具将智能合约的ABI编译为Go包，下一步就是调用“New”方法，其格式为“Newcontractname style="box-sizing: border-box; font-size: 16px; -ms-text-size-adjust: auto; -webkit-tap-highlight-color: transparent;"”，所以在我们的例子中如果你 回想一下它将是 NewStore 。 此初始化方法接收智能合约的地址，并返回可以开始与之交互的合约实例。/contractname

Commands

Store.sol

contract_load.go

solc version used for these examples

这写章节需要了解如何将智能合约的ABI编译成Go的合约文件。如果你还没看， 前先读 上一个章节 。

在上个章节我们学习了如何在Go应用程序中初始化合约实例。 现在我们将使用新合约实例提供的方法来阅读智能合约。 如果你还记得我们在部署过程中设置的合约中有一个名为 version 的全局变量。 因为它是公开的，这意味着它们将成为我们自动创建的getter函数。 常量和view函数也接受 bind.CallOpts 作为第一个参数。了解可用的具体选项要看相应类的 文档 一般情况下我们可以用 nil 。

Commands

Store.sol

contract_read.go

solc version used for these examples

这写章节需要了解如何将智能合约的ABI编译成Go的合约文件。如果你还没看， 前先读 上一个章节 。

写入智能合约需要我们用私钥来对交易事务进行签名。

我们还需要先查到nonce和燃气价格。

接下来，我们创建一个新的keyed transactor，它接收私钥。

然后我们需要设置keyed transactor的标准交易选项。

现在我们加载一个智能合约的实例。如果你还记得 上个章节 我们创建一个名为 Store 的合约，并使用 abigen 工具生成一个Go文件。 要初始化它，我们只需调用合约包的 New 方法，并提供智能合约地址和ethclient，它返回我们可以使用的合约实例。

我们创建的智能合约有一个名为 SetItem 的外部方法，它接受solidity“bytes32”格式的两个参数（key，value）。 这意味着Go合约包要求我们传递一个长度为32个字节的字节数组。 调用 SetItem 方法需要我们传递我们之前创建的 auth 对象（keyed transactor）。 在幕后，此方法将使用它的参数对此函数调用进行编码，将其设置为事务的 data 属性，并使用私钥对其进行签名。 结果将是一个已签名的事务对象。

现在我就可以看到交易已经成功被发送到了以太坊网络了:

要验证键/值是否已设置，我们可以读取智能合约中的值。

搞定！

Commands

Store.sol

contract_write.go

solc version used for these examples

有时您需要读取已部署的智能合约的字节码。 由于所有智能合约字节码都存在于区块链中，因此我们可以轻松获取它。

首先设置客户端和要读取的字节码的智能合约地址。

现在你需要调用客户端的 codeAt 方法。 codeAt 方法接受智能合约地址和可选的块编号，并以字节格式返回字节码。

你也可以在etherscan上查询16进制格式的字节码

contract_bytecode.go

首先创建一个ERC20智能合约interface。 这只是与您可以调用的函数的函数定义的契约。

然后将interface智能合约编译为JSON ABI，并使用 abigen 从ABI创建Go包。

假设我们已经像往常一样设置了以太坊客户端，我们现在可以将新的 token 包导入我们的应用程序并实例化它。这个例子里我们用 Golem 代币的地址.

我们现在可以调用任何ERC20的方法。 例如，我们可以查询用户的代币余额。

我们还可以读ERC20智能合约的公共变量。

我们可以做一些简单的数学运算将余额转换为可读的十进制格式。

同样的信息也可以在etherscan上查询:

Commands

erc20.sol

contract_read_erc20.go

solc version used for these examples

【翻译|稳定币 EOSDT】关于 Equilibrium （智能）合约的定量介绍

如果 EOS 的价值至少是 EOSDT 价值的 170％ ，那 Equilibrium 让 EOS 持有者有选择通过抵押 EOS 来生成 EOSDT 稳定币（锚定美元）的机会。

正如我们 之前的文章 所述，EOS 和 EOSIO 基础设施使用更民主的DPoS 协议。该协议的其中一个功能是让 EOS 持有者投票选出 21 个区块生产者（BP）。但前提是必须要 质押 EOS（且至少质押 3 天） 才能获得投票权。

虽然投票具有重要的财务和战略考虑因素，但连续三天冻结部分 Equilibrium 抵押品会增加 Equilibrium 的破产风险。在 之前的一篇文章 中，我们提出了第一个模型，该模型估计了三天内抵押品价值要是处于极度损失中的概率，同时也确定了一个合理安全的抵押比率。但这种模式有很大的局限性。

例如，尽管我们提到抵押比率（CR）的自然支持水平明显高于 170％ 的关键抵押率 CR，但该模型忽略了这种行为，并在独立的基础上考虑了抵押品这个变化的参数。

作为合理的代理人，让 Equilibrium 参与者实现在给定的风险水平下，给出最佳回报的目标。 特别是通过将 EOS 作为抵押品并发行 EOSDT，持仓者保持对 EOS 的曝光，并让投资不同机会的流动性得到实现：他们甚至可以进一步利用其 EOS 仓位去实现更多可能性。

其他回报和风险考虑因素：

Equilibrium 由几个变量来控制，这些变量是我们团队用尽可能安全的方式为持仓者创造流动性而设计的。

仓位所有者小组相当于一个以 EOS 合并抵押品为主要资产的公司，并且以生成 EOSDT 总额作为其主要责任。 只要公司认真致力于此，EOSDT 的价值就能持续和美元保持持平状态（1 美元= 1 EOSDT）。

EOSDT 抵押品管理类似于等待解决的 ALM 问题。

特别是通过拥有足够充足的流动资产，可以更好地保护现金流和资产负债表的偿付能力。 在 EOS 市场严重低迷的时期，公司应该通过出售（强平）资产来保护其偿付能力，并用这样的销售收益来回购其债务。 同样地，Equilibrium 将出售那些抵押不足的账户中的 EOS，以回购和销毁相应的 EOSDT。 换句话说，Equilibrium 将会在其资产负债表中减少相关数额。

资产负债表类比是 Merton 的结构信用风险模型的应用。

简而言之，公司负债的波动性通常低于其资产波动。 因此，该模型假设公司的负债是对公司资产的看涨期权的行权价。 具有行权价格 L 的现金结算看涨期权和基础 A 具有以下现金流：

1 在开始时（t = 0）：期权买方用溢价 p 来购买看涨期权

2 到期时（t = T）：

1如果 A L（资产高于负债），买方可以行使选择权以获得 A-L 的差额

2 否则期权到期毫无价值

显然， Equilibrium 中的流量比简单的看涨期权更复杂。 为了分析 Equilibrium 架构并理解其中所涉及的所有机制，我们应该消除复杂性并考虑中间的步骤。

在本文中，让我们从一个没有追加保证金的 Equilibrium 合约版本开始。 在此版本中，仓位所有者不能抵押更多的抵押品。 如果抵押品比率低于临界值水平，则仓位所有者仍将支付强平费用。

让我们来看看具体选项的细节：

1 / Equilibrium 中没有固定成熟度的概念。在经济学中指，期权是永久性的。

2 /仓位所有者可以随时赎回其仓位。 在经济学中指，美式期权。

3 /如果是以下情况，A 仓位将被平掉：

4 /破产对应的抵押品价值低于相关费率产生的 EOSDT 产生的价值（例如 equilibrium 费用）。在 Equilibrium 中，这种应计的 EOSDT 被称为当前仓位债务（CPDt）。它是随时间变化的。在经济学中指，该期权具有随时间变化的行权价格。

5 /即时终止（敲出障碍）对应于当前仓位债务的 170％ 或以下的抵押品价值。 它也是随时间变化的。 在经济学中指，该期权具有随时间变化的障碍水平。

6 /该选项具有初始成本。 在经济学中指，它是期权的溢价。

以下是对仓位所有者的合约溢价和付款资料的说明：

Equilibrium（智能）合约：连续版本（骗子版本）

价格连续性是一个理论上的概念。 Oraclize（即目前的 Provable）提供有关抵押品市场的实时信息，虽然 Equilibrium 有触发强平的自动机制，但是在提供的报价中仍然存在离散性和可能的延迟。

Oraclize 就像是足球比赛中的裁判， 裁判将不时地瞥一眼足球球门。 如果球朝正确的方向，他可能只知道距离球门大概有多远，但也许没有注意到球已经越过了球门线了。 更糟糕的是（或者更好的情况，这里的“好坏”取决于你所在的球队），也许球已经越过了球门线而被守门员防守成功了，然而这个裁判却错过了这一切！

我们把这个游戏称为注意力分散的裁判游戏。 在这种情况下，连续时间模型就像足球中的录像，问题不在于它本质上是好是坏，只是基于你所在的立场（略有？）不同。

其中最好的部分是：如果我们假设价格是连续的，那么支付概况就会简单得多。

实际上，不会发生任何毫无价值的终止事件，在中途发生的安全终止事件也是一个结束的形式。实际上，终止日期 τ 几乎是安全终止事件第一次发生时就启动了。换句话说，τ 是第一次抵押比率几乎达到当前仓位债务的 170％：仓位所有者必须（并且可以！因为没有价格差）赎回他／她的仓位以避免产生强平费用，以及他／她支出金额为 170％*CPDτ - CPDτ。

在这种情况下，裁判可以看到球几乎越过球门线：他可以在这之前吹响哨子并结束比赛！在这个例子中，游戏令人沮丧且不公平：裁判是仓位所有者，而仓位所有者显然是骗子：当灾难性的结果迫在眉睫，他能马上停止游戏吗？！用你的良心回答，答案会是什么？所以让我们把这个游戏称为不公平的裁判游戏。

我们如何为这场比赛带来公平？ 事实证明，如果仓位所有者支付大量的（Equilibrium）费用，游戏仍然可以保持在公平的水平线上。

在本文中，Equilibrium 费用与合约价值之间的平衡确实是我们主要关注的问题。 强平费用和关键抵押品水平仅仅定义了所有者支付的最小值：仓位所有者所在的位置让他们绝对不想让抵押品价值低于这些水平以下。

备注 1：在实践中，正如我们之前提到过的，到期的日期（t = τ）在一组离散的观察范围中（例如，每次从 Provable 获取价格 - 每五分钟或使用更合适的间隔时间）。

在两次观察之间出现抵押品的价格严重下跌后，该事件可能会以很小但不是不可能的概率发生。

备注 2：虽然在实践中，美国期权的行权价格也是以不连续的方式进行监控，但是仓位所有者仍然可以通过他的 EOSDT 结束仓位的持有，这样他／她的最大损失就限于溢价 p。 对行权价格的谨慎监控也是 Equilibrium 需要考虑的风险。

备注 3：在另一种情况下也可以考虑为不公平的裁判比赛，也就是当裁判员在球越过球门线后吹响哨子。 在这样的案例中，这时裁判已经变成了 Equilibrium，将会立即让仓位所有者缴纳罚金、强平仓位，避免进一步损失抵押品的价值：我们假设抵押品在没有摩擦的情况下可以立即出售。

在一个连续价格的无摩擦世界中，情况 2 和 3 不能共存。 图[1]代表各种支付概况：

正如我们从图[1]中看到的那样，在无摩擦且连续的价格世界中，红色和绿色的合约都没有低于 170％ 和 120％ 的风险。

以上图表给出的信息可能是，红色和绿色支付配置文件不一定是 Eq-0 的有效上限。 红色和绿色支付配置文件存在于连续时间世界中，而 Eq-0 存在于离散时间中。 两个监测日期期间，在注意力不集中的裁判比赛中，抵押品价值可以连续降至 170％ 以下，并有机会立即恢复。 在这种情况下，Eq-0 合约可能仍然存在，但绿色合约将被终止。

Xia 和 Zhou 提出了一种分析性的封闭式解决方案，用于为股票贷款案件中的永久美国电话定价。 这种抵押模型（几何布朗运动）不能抓取 EOS 抵押品的风险等级 ，但它是迈向更有效模型的第一步。 为了形式化这个模型，让我们来定义以下内容：

对于绿色支付配置文件：λ = 170％

每一个简化的支付概况中都可以让我们深入了解 Equilibrium 结构机制。

为了简单起见并解释架构中的机制，让我们首先关注没有惩罚、没有关键比例的情况（λ = 100％）。

λ 100％的情况似乎是类似 Ekstrom 模型 的一个很好的候选者，我们将在后续阶段进行简要分析。

第二种约束更具限制性，仅限于使用 EOS 作为抵押物，满足第二种约束的 Equilibrium 费用可以快速升到很高的水平。 仅仅由于这个原因，这种简单的结构和模型不适用于 Equilibrium。

对于 20％ 左右的波动率和 3％ 左右的 Equilibrium 费用，所需的抵押比率将高于 320％！

下面的 3D 图[2]将展示所需的比率或 Equilibrium 费用可以达到多高的水平。 在所需抵押比率高于 170％ 的背景下：

综上所述，仓位所有者在不公平的裁判游戏中的成本应远高于另一种分散注意力的裁判游戏。 这是一个完整的 Equilibrium 结构（公平游戏）开始有意义的地方：

尽管存在不完善之处，但 Xia 和 Zhou 的模型为读者提供了强平费用平衡存在的理由以及利用追加保证金的离散时间监控。

在 λ 100％的情况下，对 Xia 和 Zhou 模型的 Ekstrom 版本进行了调整 ，给出了给定的临界抵押水平（ƛ）中最小（最佳）的行使水平。

最佳行使水平应该等于或大于多项式的最高根：

在 λ= 170％时，模型为仓位所有者提供了在账户中持有的抵押品的上限水平。 高于此上限级别，仓位所有者应该选择这个时候进行最有利地选择：

该模型量化要检索的抵押品或要生成的额外 EOSDT。

所呈现的模型夸大展示了 Equilibrium 费用的价值，因为仓位所有者应该为玩不公平的裁判游戏而支付较高的费用成本。 在后续的文章中，我们需要整合 Equilibrium 的所有缺失特征（如离散、保证金调用），以产生更合理的估计。

此外，这里使用的 Black-Scholes 模型可能不适用于模拟 EOS 动力学。 进一步分析日内数据（例如 5 分钟以匹配预期的抵押品监测频率）将有助于我们确定模型的适用性。

通过本文和即将发布的内容正在呈现，我们正在用教育的方式让 Equilibrium 社区成员建立对此架构机制的信心，并最终使社区本身受益。

English version please click here .

————————————————————————————————

[1] MERTON, ON THE PRICING OF CORPORATE DEBT: THE RISK STRUCTURE OF INTEREST RATES. The Journal of Finance. Vol 29, No. 2. December 1973

[2] XIA, ZHOU, STOCK LOANS. Mathematical Finance, Vol. 17, No. 2, pp. 307-317, April 2007.

[3] EKSTROM, WANNTROP, MARGIN CALL STOCK LOANS. 2008

————————————————————————————————

Equilibrium 首席分析师

作者介绍：我是一名统计经济学家，毕业于巴黎 ENSAE ，拥有巴黎第七大学的统计和金融模型硕士学位以及在芝加哥大学的金融数学理学硕士学位。 作为 CFA 特许持有人，也是法国精算师协会的成员。 同时也是 Y＆M Advisors Ltd.的负责人/所有者。

本人的职业生涯从单一股票非标准衍生品交易组合的交易员开始，后来带领德国商业银行（Commerzbank）的衍生品销售交易团队。 同时作为一名基于波动率驱动的外汇、股票和以商品为主的国际宏观基金的投资组合经理。

关于我们，欢迎关注

官方网站：

Telegram:

币乎：

Github:

Reddit:

Medium:

Facebook:

Twitter:

智能合约solidity：转账，打款，退款，销毁等

本合约是一个比较完整的众筹合约，含：新建众筹项目，转账，打款，以及退款等功能！

编写合约时，可以直接在 线上 编写和测试部署

参与者只需记录参与者的地址和捐赠的金额

发起者则需要较多的属性，如：受益地址，目标金额，是否募资完成等！！！

另外，要通过funderMap(mapping)将捐赠者的id与捐赠者绑定在一起，从而得知是谁给受益人捐钱。

声明发起众凑的项目，并且通过neederMap(mapping)将受益人id与收益金额绑定在一起，从而可以更好的管理受益人

create众凑项目的时候，直接给定一个自增的序号当作当前众凑项目的id。create项目时，要根据前面声明的needer结构体实例，参数要一一对应。

捐赠可以根据众凑项目id给该项目捐钱（转账），当合约的方法发生转账时必须用到 payable 关键字。另外，要先校验捐赠者钱包余额够不够本次捐赠的余额，还有校验该项目是否已终止，判断都有效的情况，此时会将本次捐赠的金额直接转账到当前合约中，同时记录捐赠人数和记录捐赠者。

结束项目的原因有多种，但是这里只是用捐赠完成的原因作为例子。捐赠完成后，可以由合约发起者（本合约中也是受益者）发起将合约的钱转到自己的钱包地址中，这里同样发生了交易，所以也要用到关键字 payable 。然而，我们发现该方法中有一个 onlyOwner 修饰词，onlyOwner在下面会声明，表示只能是合约发起者才能调用该方法。

当捐款的完成后，由于合约没有销毁，捐赠者还是可以继续捐赠的，因此会导致多出的钱仍在合约账户中，所以就有了该退款的方法。该方法是将合约上的钱根据捐赠者退回给捐赠者。

源码地址：

什么是智能合约？

智能合约"(smart contract)这个术语至少可以追溯到1995年，是由多产的跨领域法律学者尼克·萨博(Nick Szabo)提出来的。他在发表在自己的网站的几篇文章中提到了智能合约的理念。他的定义如下:

"一个智能合约是一套以数字形式定义的承诺(promises)，包括合约参与方可以在上面执行这些承诺的协议。"

让我们更加详细地探讨他的定义的意思。

承诺

一套承诺指的是合约参与方同意的(经常是相互的)权利和义务。这些承诺定义了合约的本质和目的。以一个销售合约为典型例子。卖家承诺发送货物，买家承诺支付合理的货款。

数字形式

数字形式意味着合约不得不写入计算机可读的代码中。这是必须的，因为只要参与方达成协定，智能合约建立的权利和义务，是由一台计算机或者计算机网络执行的。

更进一步地说明:

(1)达成协定

智能合约的参与方什么时候达成协定呢?答案取决于特定的智能合约实施。一般而言，当参与方通过在合约宿主平台上安装合约，致力于合约的执行时，合约就被发现了。

(2)合约执行

"执行"的真正意思也依赖于实施。一般而言，执行意味着通过技术手段积极实施。

(3)计算机可读的代码

另外，合约需要的特定"数字形式"非常依赖于参与方同意使用的协议。

协议

协议是技术实现(technical implementation)，在这个基础上，合约承诺被实现，或者合约承诺实现被记录下来。选择哪个协议取决于许多因素，最重要的因素是在合约履行期间，被交易资产的本质。

再次以销售合约为例。假设，参与方同意货款以比特币支付。选择的协议很明显将会是比特币协议，在此协议上，智能合约被实施。因此，合约必须要用到的"数字形式"就是比特币脚本语言。比特币脚本语言是一种非图灵完备的、命令式的、基于栈的编程语言，类似于Forth。

版权声明：除非特别标注，否则均为本站原创文章，转载时请以链接形式注明文章出处。