区块链技术具有独特的属性，可用于创建创新的去中心化保险产品，为保险供应商和客户带来诸多好处。在本技术教程中，我们将向您展示：
分散参数保险合同的主要特征
为什么Chainlink predictor会在这些新的保险产品中发挥重要作用？
在分散保险合同中使用链式价格反馈的优势
如何将所有东西放在一起，创建一个可用的参数作物保险合同
如何使用链式节点自动更新保险合同
下面这个例子的完整代码可以在Remix或者GitHub上查看，包括下面提到的所有函数和所有需要的helper函数。
分散保险分散保险使用区块链技术和智能合同来取代传统的保险协议。分散型保险产品有三个主要特点。
数据驱动自动化去中心化保险合同最重要的一点就是数据驱动，自动执行。这意味着保险合同自动执行逻辑，无需人工干预，依靠从外部获取的安全准确的数据来确定合同逻辑的执行。这些保险智能合约还可以连接外部输出，如支付处理器或企业财务系统，以方便触发支付。
智能合同智能合同代表保险公司和客户之间的保险合同。它实质上是保险公司对特定类型的损失、损害或责任赔偿客户的承诺。如果是参数保险，就是对冲特定事件的风险。它包含保险合同的所有详细信息，如指数(如作物保险合同中的降雨量)、客户付款的详细信息(如钱包地址或外部支付系统的客户ID)、合同日期或期限、指数的测量地点、阈值和约定的赔偿值。由于保险合同是在通常运行在大量节点上的区块链上存储和执行的，因此它具有高度的确定性，不容易被黑客攻击或篡改。
理赔流程不同于传统的保险合同。在分散式保险合同中，索赔结算流程作为合同执行的一部分自动处理。客户不需要提交索赔，不需要提供任何证据，也不需要与保险公司或智能合同进行任何交互。当智能合同认为应该付款时，付款将作为合同执行的一部分自动触发。这可以通过直接在链上支付客户，或者通过智能合约连接的外部支付渠道或金融系统来实现。
创建数据驱动的参数化保险合同现在我们知道了什么构成了分散式参数化保险合同，我们将通过构建一个简单的示例来演示上述三个概念。在此场景中，我们将创建一个参数化的作物保险合同，具有以下属性：
如果在规定时间内没有下雨，合同将向客户支付约定的价值，目前定为三天，以方便演示。该合同将从两个不同的数据源获取降雨数据，以缓解任何数据完整性问题，然后对结果进行平均。
该合同将由ETH全额出资，相当于美元价值，用于约定的赔偿金额，以确保触发索赔时的完全确定性。它将使用Chainlink ETH/USD价格来确定合同所需的ETH数量。
分散保险结构
建立保险合同工厂首先，我们需要创建一个主‘合同工厂’合同，它将生成多个保险协议，并允许我们与它们进行交互。这份合约将归保险公司所有，将为每份生成的保险合约提供充足的ETH和LINK资金，以确保一旦保险合约生成，所有需要的操作，包括支付，都可以在其整个存续期间执行。
首先，我们的《担保法》包含两种合同，一种是保险供应商合同，另一种是保险合同。保险供应商合同将生成许多保险合同。
InsuranceProvider合同的构造者初始化Kovan网络上的Chainlink ETH/USD价格馈送。InsuranceContract的构造者定义如下，后面会进一步丰富。
保险供应商合同的一般结构如下：
每个生成的合同都存储在保险合同的合同映射中，并以生成的合同的以太坊地址作为密钥。该值是实例化的保险合同可靠性智能合同。
newContract函数接收所需的输入并生成一个新的保险合同，根据之前定义的构造函数传递所有所需的参数。它还会发送与支付金额相等的ETH，以便生成的合同资金充足。它使用Chainlink ETH/USD价格馈送来完成这种转换。然后，它将生成的合同存储在“合同”映射中，并将足够的链接传输到生成的合同中，以便它有足够的每天两次的数据请求和余量。这个保证金是考虑到合同到期后可能需要通知的时间。当合同结束时，任何剩余的链接将被返回给保险提供商。
UpdateContract功能用于更新保险合同的数据，检查是否达到触发支付的阈值或合同是否到了终止日期。
最后，getContractRainfall函数用于返回给定保险合同的降雨量(以毫米为单位)，getContractRequestCount函数用于检查有多少数据请求成功返回给保险合同。
获取外部数据生成的保险合同需要获取外部数据才能正常执行。这就是Chainlink网络发挥作用的地方，因为您可以使用它将保险合同连接到多个降雨量数据源。在这个例子中，我们将在两个不同的Chainlink节点上使用Job Specification，从两个不同的weather APIs中获取数据，然后在链上进行平均以获得最终结果。这两个天气API都需要注册，以便在每个请求中获得一个免费的API密钥。
-韦瑟比特天气API
-连接池GETUint256作业
– Steelblock GETUint256作业
一旦我们写下了Weather API键、上面的作业规范Id和oracle contract，我们现在就可以创建InsuranceContract合同并填写必需的常量字段。在生产场景中，这些常量字段将被私有地存储在Chainlink节点上，该节点在链上是不可见的，但是为了方便后面的演示，它们被留在了契约中。我们还存储所需的JSON路径。当Chainlink node从每个API获取天气数据时，我们必须遍历这些路径来查找每天的总降雨量(以毫米为单位)。
完成保险合同的下一步是完成保险合同，它代表客户和保险公司之间的作物保险合同。
协定被实例化，所有必需的值都被传递到构造函数中。它还做了以下工作：
使用Chainlink ETH/USD价格馈送检查是否发送了足够的ETH，以确保触发支付时有足够的资金。
设置合同执行所需的一些变量。
设置JobId和oracle array以包含从上面“获取外部数据”一节中的两个jobspecifications获得的值。但是，如果要运行自己的Chainlink节点，请将这两个请求都设置为使用您的作业说明和oracle contract，以便您可以看到每个作业的输出。为此，您需要在market.link上创建一个新的作业规范。与本例中一样，您只需将runlog initiator中的地址修改为您的oracle合同。
然后，我们创建一个函数来调用，从每个Chainlink节点和weather API请求降雨量数据。该函数由主保险提供商合同调用。它为每个请求建立所需的URL，然后为每个请求调用checkRainfall函数。但在此之前，它调用了一个checkEndContract函数来检查合同结束日期是否已到，只有在合同仍然有效的情况下才会继续。这个checkEndContract函数定义如下。
现在我们可以创建checkRainfall函数。这是实际执行外部数据请求的函数。它接收所有必需的参数，构建一个请求，然后将其发送到指定的链接节点oracle contract。
在我们的演示中，传递给“checkRainfall”函数的“_ _path”变量的值用于遍历请求返回的JSON路径，并找到当前的降雨量。这些值取决于调用哪个天气API，这两个选项都存储在我们的契约中的静态变量中，并在需要时传递给` _ path '函数参数。
世界天气在线API响应格式
Weatherbit API响应格式
然后，我们创建一个回调函数，在Chainlink节点发回响应时调用。该功能接收指定位置的最新降雨量数据。如果是第二次数据更新(即两个请求都被应答)，它执行平均计算，然后用最新的降雨量数据更新合同。
回调函数还根据当前合约的雨量数据检查参数化损失是否实现。在本例中，它根据给定的阈值检查连续无雨天数。如果满足补偿条件，则调用payoutContract函数。
接下来，我们创建payoutContract函数。作为索赔处理步骤，该功能执行保险公司向客户自动支付约定价值。我们在这里特别注意确保它只能在契约仍然有效(即未完成)时被调用，并且只能由其他契约函数在内部调用。它还返回保险提供商主合同的任何剩余链接，并将合同设置为完成状态，以防止对其进行任何进一步的操作。
}
最后，我们创建一个函数来处理这样一个场景：合同结束日期已经到了，但付款尚未触发。我们需要归还合同中的资金，然后标记为结束。该函数的执行检查是否为整个合同接收了足够的数据请求。每天需要接收一个数据请求，总共只允许错过一个请求。因此，如果契约的持续时间为30天，则必须至少有29个成功的数据请求。如果合同在其生命周期中收到足够多的请求，所有资金都将返回给保险提供商。否则，如果在整个合同期限内没有足够的数据请求，客户将自动收到保费作为退款，保险公司将收回任何剩余资金。
该方案还使用Chainlink ETH/USD价格反馈来确定正确的ETH数量，并将其返回给客户。这种检查为客户提供了一定程度的保证，即保险提供商不会试图通过在结束日期到来之前不更新降雨量数据来玩弄合同。该函数还会将任何剩余的链接返回给保险提供商合同。
部署和测试合同。首先，我们需要部署InsuranceProvider契约，并为它提供一些ETH和LINK，以便在生成的InsuranceContract契约中使用。完成所有这些工作后，我们可以创建一个新的InsuranceContract并传递所需的值。请注意以下几点。
持续时间的单位是秒。在本演示中，1天缩短为60秒(在DAY_IN_SECONDS常量中指定)，因此300秒的合同期代表5天。
Premium和payoutValue参数以美元为单位，乘以10000000，例如，100美元就是100000000。
创建新的保险合同。
当保险合同生成时，我们可以通过Etherscan中的事务或者通过事务输出来获取它的地址。
在Etherscan上查看生成的合同
然后，我们可以将生成的合同地址传输到updateContract函数中，并开始将降雨量数据传输到合同中。
续订保险合同
当两个Chainlink节点都处理了作业请求并返回结果时，我们可以调用getContractRainfall '和getContractRequestCount '函数来查看平均降雨量的更新和数据请求的增加。数据请求意味着两个节点都返回一个结果，该结果被平均并存储在契约中。在本例中，爱荷华州两个数据源的当前平均降雨量为0.6毫米。我们还可以调用帮助函数getContractStatus来验证合同是否仍然有效。
获取保险合同的状态
在合约有效期内(本演示5次/300秒)，每天都要重复这一步(本例1分钟)来结束合约。如果无雨天数达到“干旱天数阈值”中设置的阈值，合同将向客户支付约定的金额，合同状态将终止。
出于演示的目的，我们为一个没有下雨的地方创建了另一个保险合同，并在三分钟内重复上述步骤三次，演示支付时会发生什么。在这种情况下，我们可以看到最近的降雨量为0，请求数为3，合同不再有效。
获取保险合同的状态
如果我们再去以太坊查看合同，会发现约定的美元ETH赔偿价值已经转回了上面创建合同时指定的客户钱包地址，保险合同不再持有任何ETH或LINK。由于保险合同现在处于已完成状态，对保险合同的任何后续操作都将被拒绝。
核实保险合同的支付
自动更新数据在当前版本的契约中，必须有人手动调用updateContract函数，使契约与Chainlink节点通信并获取降雨数据。这并不理想，因为在整个合同期内需要多次调用它。一个好的自动化方法是使用cron发起的Chainlink节点。
Cron initiator是一种通过使用简单的Cron语法在Chainlink节点上调度循环作业的方法。在这种情况下，我们可以做的是在Chainlink节点上创建一个新的作业规范，并使用cron initiator每天触发一次作业规范。但出于演示的目的，我们将根据前面提到的常量SECONDS_IN_DAY将其设置为每分钟触发一次。
每次Cron作业触发作业规范的执行时，作业规范的其余部分将简单地调用部署的智能合同updateContract函数。这个想法是，保险前端将有所有相关的细节(合同地址，开始日期，结束日期)，并可以通过他们。
我们的想法是，保险应用的去中心化前端将向Chainlink节点API发送请求，动态生成新的作业规范，并提供节点自动开始定期更新保险合同所需的所有正确细节，而不必通过Chainlink节点前端接口手动创建这个工作规范。
为此，首先我们需要Chainlink节点的IP地址和端口，以及登录节点的用户名和密码。这些是用于生成下一个请求的cookiefile。
完成这些任务后，我们将得到一个响应，显示身份验证成功。
然后，我们可以向Chainlink节点API发送另一个POST请求，这次是向/v2/specs端点发送。请求中的JSON是生成的定期更新的保险合同的地址，以及开始和结束的日期/时间(如果需要，带有指定的时间偏移)，以便节点知道何时停止定期更新保险合同。
该命令将返回一条成功消息，其中包含生成的作业规范的详细信息。之后，您可以登录到Chainlink节点的前端，并查看新创建的作业规范。
Cron启动器工作规范语法
创建作业规范后，它将根据cron initiator中设置的参数开始执行请求。我们可以在Chainlink节点的前端对此进行监控。
成功完成请求后，节点可以返回到智能合约，并看到其状态已被成功更新。
在这篇技术文章中，我们展示了如何建立一个分散的农作物保险产品来补偿农民在干旱时期的损失。我们已经展示了拥有准确和分散的保险合同数据的重要性，以及Chainlink oracles在安全提供这些数据方面的作用。
我们还演示了如何使用连接到外部数据和事件的确定性智能合同来彻底降低处理保险索赔的开销和管理成本，以及如何使用Chainlink来分散费用交付，以在合同条款基于美元但以加密货币支付时准确确定正确的支付金额。最后，我们还演示了如何将Chainlink node cron启动器与Chainlink node API相结合，以自动调度和执行智能合约更新。
虽然这个演示包含许多功能，但它可以用作构建完整的功能性分散保险产品的基本模板。开发人员可以以各种方式在这个模板上进行构建，比如使用Chainlink聚合器或PreCoordinator契约来移除人工数据聚合。另一种选择是将保险合同证券化，并将其作为DeFi生态系统或其他市场的抵押品。
如果您是一名开发人员，并希望将您的智能合约连接到链外数据和系统，请访问开发文档并加入关于Discord的技术讨论。如果您想安排电话讨论更深入的整合，请在此联系。