通過Chainlink預言機構建參數化保險智能合約

2021-01-18 Chainlink預言機


區塊鏈技術具有獨特的屬性，可以用來創建創新性的去中心化保險產品，為保險供應商和客戶帶來諸多好處。在本技術教程中，我們將向您展示：


去中心化參數化保險合約的主要特點

為什麼Chainlink預言機在這些新的保險產品中起著舉足輕重的作用

在去中心化保險合約中使用Chainlink Price Feed的優勢

如何把所有的東西放在一起，創建一個可用的參數化作物保險合約

如何使用Chainlink節點來自動更新保險合約


下面例子的完整代碼可以在Remix或GitHub上查看，包括下面提到的所有功能以及所有需要的幫助函數。



去中心化保險利用區塊鏈技術和智能合約來取代傳統的保險協議。去中心化保險產品主要有三大特點。



去中心化保險合約最重要的一點是，它是數據驅動和自動執行的。這意味著保險合約在不需要人工幹預的情況下自動執行邏輯，依靠從外部獲取的安全準確的數據來決定合約邏輯的執行。這些保險智能合約還可以與外部輸出連接，如支付處理器或企業財務系統，以方便觸發支付。



智能合約代表了保險人與客戶之間的保險合同，它實質上是保險人對客戶指定類型的損失、破壞或責任進行賠償的承諾，如果是參數保險，則是對衝特定事件發生的風險。它包含了保險合同的所有細節，如指數（例如農作物保險合同中的降雨量）、客戶支付的細節（如錢包地址，或外部支付系統的客戶ID）、合同日期或期限、指數的測量地點、閾值和商定的賠付值。由於保險合約存儲和執行在通常運行在大量節點上的區塊鏈上，因此它具有高度確定性，不容易被黑客攻擊或篡改。



與傳統的保險合同不同，去中心化保險合約中，理賠過程是作為合約執行的一部分自動處理的。客戶不需要提交理賠，不需要提供任何證據，也不需要與保險公司或智能合約有任何互動。當智能合約認為應該發生賠付時，賠付將作為合約執行的一部分自動觸發。這可以通過直接向客戶進行鏈上支付，也可以通過智能合約連接的外部支付通道或金融系統來完成。



現在，我們已經了解了什麼構成了一個去中心化的參數化保險合約，我們將通過構建一個簡單的例子來展示上述三個概念。在這個場景中，我們將創建一個具有以下屬性的參數化農作物保險合約：



首先，我們需要創建一個主 "合約工廠 "合約，它將生成多個保險協議，並允許我們與它們進行交互。這個合約將由保險公司擁有，並為每個生成的保險合約提供足夠的ETH和LINK資金，以確保保險合約一旦生成，就能在其整個存續期內執行所有需要的操作，包括賠付。


首先，我們的Solidity代碼包含兩個合約，一個是InsuranceProvider合約，一個是InsuranceContract合約。InsuranceProvider合約會生成很多保險合約。


InsuranceProvider合約的構造函數初始化了Kovan網絡上的Chainlink ETH/USD Price Feed。InsuranceContract合約的構造函數定義如下，後面會進一步充實。


pragma solidity 0.4.24;pragma experimental ABIEncoderV2;
import "chainlink/contracts/ChainlinkClient.sol";import "chainlink/contracts/vendor/Ownable.sol";import "chainlink/contracts/interfaces/LinkTokenInterface.sol";
contract InsuranceProvider {        constructor()   public payable {        priceFeed =AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);    }
}
contract InsuranceContract is ChainlinkClient, Ownable  {        constructor(address _client, uint_duration, uint _premium, uint _payoutValue, string _cropLocation, address_link, uint256 _oraclePaymentAmount) payable Ownable() public {            }}

InsuranceProvider合約的一般結構如下：


mapping (address => InsuranceContract) contracts;


function newContract(address_client, uint _duration, uint _premium, uint _payoutValue, string_cropLocation) public payable onlyOwner() returns(address) {        
                InsuranceContract i = (newInsuranceContract).value((_payoutValue * 1ether).div(uint(getLatestPrice())))(_client, _duration, _premium, _payoutValue,_cropLocation, LINK_KOVAN,ORACLE_PAYMENT);                 contracts[address(i)] = i;                          emit contractCreated(address(i),msg.value, _payoutValue);                        LinkTokenInterface link =LinkTokenInterface(i.getChainlinkToken());        link.transfer(address(i),((_duration.div(DAY_IN_SECONDS)) + 2) * ORACLE_PAYMENT.mul(2));                        return address(i);            }


function updateContract(address _contract) external {        InsuranceContract i =InsuranceContract(_contract);        i.updateContract();    }


function getContractRainfall(address _contract) external view returns(uint){        InsuranceContract i =InsuranceContract(_contract);        return i.getCurrentRainfall();    }
    functiongetContractRequestCount(address _contract) external view returns(uint) {        InsuranceContract i =InsuranceContract(_contract);        return i.getRequestCount();    }


生成的保險合約需要獲得外部數據才能正常執行。這就是Chainlink網絡發揮作用的地方，因為你可以使用它將保險合約連接到多個降雨數據源。在這個例子中，我們將在兩個不同的Chainlink節點上使用Job Specification，從兩個不同的天氣API中獲取數據，然後將在鏈上取平均值來得出最終結果。這兩個天氣API都需要註冊獲得一個免費的API密鑰在每個請求中使用。


一旦我們記下了Weather API key以及上面的Job Specification Id和oracle合約，我們現在就可以創建 `InsuranceContract`合約，填寫所需的常量欄位。在生產場景中，這些常量欄位會被私有存儲在Chainlink節點上，在鏈上是不可見的，但為了方便跟隨演示，它們被留在了合約中。我們還存儲了所需的JSON路徑，當Chainlink節點從每個API中獲取天氣數據時，我們要遍歷這些路徑來找到每日總降雨量（以毫米為單位）。

    string constant WORLD_WEATHER_ONLINE_URL ="http://api.worldweatheronline.com/premium/v1/weather.ashx?";    string constantWORLD_WEATHER_ONLINE_KEY = "insert API key here";    string constantWORLD_WEATHER_ONLINE_PATH ="data.current_condition.0.precipMM";          string constant WEATHERBIT_URL ="https://api.weatherbit.io/v2.0/current?";    string constant WEATHERBIT_KEY ="insert API key here";    string constant WEATHERBIT_PATH ="data.0.precip";


下一步是完成保險合約（InsuranceContract），它代表客戶和保險公司之間的作物保險合同。

該合約被實例化，所有所需的值都傳遞到構造函數中。它還做了以下工作：

使用Chainlink ETH/USD Price Feed來檢查是否有足夠的ETH被發送，以確保在觸發支付時有足夠的資金。
- 設置合約執行所需的一些變量
將JobId和oracle數組設置為包含從上面「獲取外部數據」部分的兩個Job Specification中獲取的值。然而，如果你想運行你自己的Chainlink節點，將兩個請求都設置為使用你的Job Specification和oracle合約，這樣就可以看到每個Job的輸出。這樣做需要在market.link上創建一個新的Job Specification，和這個例子一樣，只需要修改runlog initiator中的地址為你的oracle contract。

constructor(address _client,uint _duration, uint _premium, uint _payoutValue, string _cropLocation,                 address _link, uint256_oraclePaymentAmount)  payable Ownable()public {                priceFeed =AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);                        setChainlinkToken(_link);        oraclePaymentAmount =_oraclePaymentAmount;                        require(msg.value >=_payoutValue.div(uint(getLatestPrice())), "Not enough funds sent tocontract");                        insurer= msg.sender;        client = _client;        startDate = now + DAY_IN_SECONDS;        duration = _duration;        premium = _premium;        payoutValue = _payoutValue;        daysWithoutRain = 0;        contractActive = true;        cropLocation = _cropLocation;                        oracles[0] =0x05c8fadf1798437c143683e665800d58a42b6e19;        oracles[1] =0x05c8fadf1798437c143683e665800d58a42b6e19;        jobIds[0] = 'a17e8fbf4cbf46eeb79e04b3eb864a4e';        jobIds[1] ='a17e8fbf4cbf46eeb79e04b3eb864a4e';
        emitcontractCreated(insurer,                            client,                            duration,                            premium,                             payoutValue);    }

然後，我們創建一個函數來調用，以從每個Chainlink節點和天氣API中請求降雨數據。這個函數被主保險提供者合約所調用。它為每個請求建立了所需的URL，然後為每個請求調用`checkRainfall`函數。但在這之前，它調用了一個`checkEndContract`函數來檢查合約結束日期是否已經到了，並且只有在合約仍然有效的情況下才會繼續。這個`checkEndContract`函數定義如下。

function updateContract() publiconContractActive() returns (bytes32 requestId)  {                checkEndContract();                        if (contractActive) {            dataRequestsSent = 0;                        string memory url =string(abi.encodePacked(WORLD_WEATHER_ONLINE_URL,"key=",WORLD_WEATHER_ONLINE_KEY,"&q=",cropLocation,"&format=json&num_of_days=1"));            checkRainfall(oracles[0],jobIds[0], url, WORLD_WEATHER_ONLINE_PATH);
                                    url =string(abi.encodePacked(WEATHERBIT_URL,"city=",cropLocation,"&key=",WEATHERBIT_KEY));            checkRainfall(oracles[1],jobIds[1], url, WEATHERBIT_PATH);           }    }

現在我們可以創建`checkRainfall`函數。這是實際執行外部數據請求的函數。它接收所有需要的參數，建立一個請求，然後將其發送到指定的Chainlink節點oracle合約。

在我們的演示中，傳遞到`checkRainfall`函數中的`_path`變量的值用來遍歷請求返回的JSON的路徑，找到當前的降雨量。這些值取決於調用哪一個天氣API，這兩個選項都存儲在我們的合約中的靜態變量中，並根據需要傳遞到`_path`函數參數中。


 string constant WORLD_WEATHER_ONLINE_PATH ="data.current_condition.0.precipMM";    string constant WEATHERBIT_PATH ="data.0.precip";
function checkRainfall(address _oracle, bytes32 _jobId, string _url, string_path) private onContractActive() returns (bytes32 requestId)   {
                Chainlink.Request memory req =buildChainlinkRequest(_jobId, address(this),this.checkRainfallCallBack.selector);                   req.add("get", _url);        req.add("path", _path);        req.addInt("times",100);                requestId =sendChainlinkRequestTo(_oracle, req, oraclePaymentAmount);                     emitdataRequestSent(requestId);    }

然後，我們創建一個回調函數，當Chainlink節點發迴響應時調用。這個函數接收指定位置的更新雨量數據，如果是第二次數據更新（即兩個請求的都得到了響應），則執行取平均計算，然後用最新的雨量數據更新合約。

回調函數還根據當前合約的降雨量數據檢查是否實現了參數化損失。本例中，它根據給定的閾值檢查連續無雨天數。如果滿足賠付條件，則調用`payoutContract`函數。

 function checkRainfallCallBack(bytes32_requestId, uint256 _rainfall) public recordChainlinkFulfillment(_requestId)onContractActive() callFrequencyOncePerDay() {              currentRainfallList[dataRequestsSent] = _rainfall;        dataRequestsSent =dataRequestsSent + 1;                     if (dataRequestsSent > 1){          currentRainfall =(currentRainfallList[0].add(currentRainfallList[1]).div(2));          currentRainfallDateChecked =now;          requestCount +=1;                            if (currentRainfall == 0 ) {              daysWithoutRain += 1;          } else {                            daysWithoutRain = 0;              emitranfallThresholdReset(currentRainfall);          }                 if (daysWithoutRain >=DROUGHT_DAYS_THRESDHOLD) {                              payOutContract();          }       }              emit dataReceived(_rainfall);            }
接下來我們創建`payoutContract`函數。這個函數作為理賠處理步驟，執行保險人向客戶自動支付約定的價值。我們在這裡格外小心，確保它只能在合約仍處於激活狀態（即未結束）時被調用，並且只能被其他合約函數在內部調用。它還將任何剩餘的LINK返回到保險提供商主合同，並將合約設置為已完成狀態，以防止對其進行任何進一步的操作。

function payOutContract()private onContractActive()  {                       client.transfer(address(this).balance);                        LinkTokenInterface link =LinkTokenInterface(chainlinkTokenAddress());        require(link.transfer(insurer,link.balanceOf(address(this))), "Unable to transfer");                emit contractPaidOut(now,payoutValue, currentRainfall);                                contractActive = false;        contractPaid = true;        }
 
最後，我們創建一個函數來處理這樣的場景：合約結束日期已經到了，還沒有觸發支付，我們需要歸還合約中的資金，然後標記為結束。該函數執行檢查整個合約是否收到足夠的數據請求。每天需要收到一個數據請求，總計只允許漏掉一個請求。因此，如果合約的持續時間為30天，則必須有至少29個成功的數據請求。如果合約在其生命周期內收到足夠的請求，所有資金將被退回給保險供應商。否則，如果在整個合約的存續期內沒有足夠的數據請求，客戶就會自動收到作為退款的保費，而保險商則會拿回任何剩餘的資金。

這個方案還利用Chainlink ETH/USD Price Feed來確定正確的ETH數量，將其返還給客戶。這個檢查給客戶一定程度的保證，保險提供商不會試圖通過不更新降雨量數據來玩弄合約，直到達到結束日期。該函數還將返回任何剩餘的LINK回保險提供商合約。


function checkEndContract()private onContractEnded()   {                        if (requestCount >=(duration.div(DAY_IN_SECONDS) - 1)) {                       insurer.transfer(address(this).balance);        } else {            client.transfer(premium.div(uint(getLatestPrice())));           insurer.transfer(address(this).balance);        }                       LinkTokenInterface link =LinkTokenInterface(chainlinkTokenAddress());        require(link.transfer(insurer,link.balanceOf(address(this))), "Unable to transfer remaining LINKtokens");                        contractActive = false;        emit contractEnded(now,address(this).balance);    }


首先，我們需要部署InsuranceProvider合約，並用一些ETH和LINK為其提供資金，以便在生成的InsuranceContract合約中使用。

完成這些工作後，我們就可以創建一個新的InsuranceContract，傳遞所需的值。請注意以下幾點。


創建一個新的保險合同

當保險合同生成後，我們可以通過Etherscan中的交易或通過交易輸出獲取其地址。

在Etherscan上查看生成的合同

然後，我們可以將生成的合同地址，傳入`updateContract`函數，開始將降雨量數據傳入合同中。

更新保險合約

當兩個Chainlink節點都處理了作業請求並返回一個結果後，我們就可以調用`getContractRainfall`和`getContractRequestCount`函數來查看平均降雨量的更新，以及數據請求數的增加。一個數據請求意味著兩個節點都返回了一個結果，取平均值之後存儲在合約中。在本例中，愛荷華州目前兩個數據源的平均降雨量為0.6mm。我們還可以調用幫助函數`getContractStatus`來驗證合同是否還處於活動狀態。

獲取保險合約的狀態

在合約有效期內（本演示為5次/300秒），每天（本例為1分鐘）應重複此步驟，結束合約。如果無雨天數達到`DROUGHT_DAYS_THRESHOLD`中設置的閾值，合約將向客戶支付約定的金額，合約狀態結束。

為了達到演示的目的，我們又為一個沒有降雨的地點創建了一個保險合約，並在三分鐘內重複上述步驟三次，以演示在賠付時發生的情況。在這個案例中，我們可以看到最新的降雨量為0，請求次數為3，合同不再處於活動狀態。

獲取保險合同的狀態

如果我們再去以太坊上檢查該合約，就會發現約定的美元ETH賠付值已經轉回了上面創建合約時指定的客戶錢包地址，而保險合約已經不再持有任何ETH或LINK。由於保險合約現在處於完成狀態，所以後續對保險合約的任何操作都會被拒絕。


在當前版本的合同中，必須有人手動調用`updateContract`函數來讓合約與Chainlink節點通信並獲取降雨量數據。這並不理想，因為它需要在整個合約期限內多次調用。一個好的自動化方法是利用Chainlink節點的cron initiator。

cron initiator是一種使用簡單的cron語法在Chainlink節點上調度循環Job的方法。在這種情況下，我們可以做的是在Chainlink節點上創建一個新的Job Specification，使用cron initiator每天觸發一次Job Specification。但為了本演示的目的，我們將根據前面提到的常量SECONDS_IN_DAY，將其設置為每分鐘觸發一次。

Job Specification的剩餘部分將簡單地在每次Cron job觸發執行Job Specification時，調用部署的智能合約`updateContract`函數。這個想法是，保險前端將擁有所有相關的細節（合約地址，開始日期，結束日期），並可以將它們傳遞進來。

{   "initiators": [      {         "type":"cron",         "params": {            "schedule":"CRON_TZ=UTC 0/' + 6 + ' * * * * *"         }      }   ],   "tasks": [      {         "type":"ethtx",         "confirmations":0,         "params": {            "address": "' + address +'",            "functionSelector":"checkContract()"         }      }   ],   "startAt": "' +startDate + '",   "endAt": "' + endDate +'"}

我們的想法是，去中心化的保險應用前端將向Chainlink節點API發送請求，動態生成新的Job Specification，並提供節點自動開始定期更新保險合同所需的所有正確細節，而不必通過Chainlink節點前端接口手動創建這個工作規範。

要做到這一點，首先我們需要Chainlink節點的IP位址和埠，以及登錄節點的用戶名和密碼。這些都是用來生成下一次請求的cookiefile。

curl -c cookiefile -X POST -H 'Content-Type: application/json' -d '{"email":"user@email.com", "password":"password"}' http:

完成了這些工作後，我們會得到一個響應，以顯示認證成功。

{"data":{"type":"session","id":"sessionID","attributes":{"authenticated":true}}}

然後我們可以向Chainlink節點API發送另一個POST請求，這次是向/v2/specs端點發送。請求中的JSON是定期更新的生成的保險合約的地址，以及開始和結束的日期/時間（如果需要的話，還有指定的時間偏移），這樣節點就知道什麼時候停止定期更新保險合約。

curl  -b cookiefile -X POST -H 'Content-Type:application/json' -d'{"initiators":[{"type":"cron","params":{"schedule":"CRON_TZ=UTC0/60 * * * * *"}}],"tasks":[{"type":"ethtx","confirmations":0,"params":{"address":"0xdC71C577A67058fE1fF4Df8654291e00deC28Fbf","functionSelector":"updateContract()"}}],"startAt":"2020-11-10T15:37:00+10:30","endAt":"2020-11-10T15:42:00+10:30"}' http:
這個命令會在返回一個成功的消息，其中包含了生成的Job Specification的細節。在這之後，你就可以登錄到Chainlink節點前端，並看到新創建的Job Specification。

Cron啟動器工作規範語法

Job Specification創建後，它就會按照cron initiator中設置的參數開始執行請求。我們可以在Chainlink節點前端監控到這一點。


節點成功地完成了請求後可以回到智能合約，看到它的狀態已經成功更新。


在這篇技術文章中，我們已經演示了如何建立一個去中心化的作物保險產品，以補償農民的乾旱期。我們已經展示了保險合約擁有準確和去中心化數據的重要性，以及Chainlink oracles在安全提供這些數據方面的作用。

我們還演示了如何利用連接到外部數據和事件的確定性智能合約來徹底降低處理保險理賠的開銷和管理成本，以及在合約條款以美元為基礎卻以加密貨幣支付的情況下，如何利用Chainlink去中心化餵價送來準確確定正確的賠付金額。最後，我們還演示了Chainlink節點cron initiator如何與Chainlink節點API結合使用，以自動安排和執行智能合約更新。

雖然這個演示包含了許多功能，但它可以作為一個基本模板來構建一個完整的、功能豐富的去中心化保險產品。開發者可以在這個模板的基礎上以各種方式進行構建，比如去掉人工數據聚合，利用Chainlink的聚合器或PreCoordinator合約。另一種選擇是將保險合約證券化，並將其作為DeFi生態系統或其他市場的抵押品。

如果您是開發人員，並希望將您的智能合約連接到鏈外數據和系統，請訪問開發文檔並加入Discord上的技術討論。如果您想安排電話討論更深入的集成，請在這裡聯繫。

相關焦點

  • Chainlink 可驗證隨機函數詳解
    Chainlink VRF將為眾多優秀的智能合約項目帶來巨大價值，尤其能證明智能合約使用的隨機數不可被篡改和操控。Chainlink VRF有助於加速區塊鏈遊戲、安全和layer2協議等眾多領域的智能合約開發進程。開發者可以輕鬆集成Chainlink VRF，參考我們近期發布的開發者文檔，在智能合約中使用可驗證的隨機數。
  • 萬向區塊鏈行業研究:詳解去中心化預言機的設計
    隨著DeFi及其他公鏈應用用戶基數的擴大，去中心化預言機將成為必要基礎設施，而跨預言機的應用，是提升數據源安全性的一大趨勢。 加密世界與現實世界的運行邏輯存在相當大的差異。加密世界通過共識機制、密碼學、分布式節點及智能合約在鏈上運行。而在智能合約中，輸入X變量，智能合約執行Y結果是可以預期的，此結果不可逆且具備確定性及可信賴性。
  • 去中心化預言機項目Chainlink的工作原理解析
    以太坊的智能合約是「圖靈完備（Turing Complete）」的，某種意義上可以看做一個圖靈機，所以以太坊的設計者借鑑這個概念，把向「圖靈完備的智能合約」這個圖靈機輸入信息的也被稱為預言機oracle。所以說「預言機」這個名字並不是區塊鏈技術領域內的獨創概念，它來源於非常早期的計算機抽象設計，在密碼學等領域內也都有類似的概念。
  • 幣小寶一文深度解讀ChainLink
    據幣小寶查證，ChainLink提供的是智能合約去中心化預言機網絡解決方案。這一句話讀來十分拗口，分兩點來解釋：智能合約和預言機網絡。智能合約就是在一定條件下，計算機可以自動執行的合同。比如公司每月10號發工資，這個如果寫到智能合約裡，那麼只要滿足每月10號這個條件，工資就會自動到帳，合約一旦寫好，自動執行，無需人為幹預。
  • 聯盟分析-政策法規 | DeFi閃電貸遭攻擊背後——DeFi智能合約安全...
    DeFi安全事件主要是由於其智能合約安全漏洞的問題，在此大背景下，本文對DeFi智能合約安全漏洞的相關法律問題進行研究。01DeFi與DeFi產品的定義  DeFi，即Decentralized Finance，被稱作分布式金融或者去中心化金融，去中心化交易所、網絡借貸平臺、保險平臺、去中心化錢包等都是屬於DeFi範疇。
  • Chainlink中國負責人:預言機的未來絕不僅限於DeFi
    由於區塊鏈智能合約和外部世界無法直接進行數據交互，例如智能合約無法獲取外部交易所加密貨幣的價格信息，因此，就需要一個「中間件」將鏈下數據傳輸至鏈上。預言機存在的意義其實是滿足了區塊鏈智能合約對鏈下數據的需求，這些海量的數據通過預言機傳輸到區塊鏈網絡上，很大程度上豐富了鏈上生態和應用操作。當然，除了將鏈下的數據傳輸到鏈上，預言機也可以將區塊鏈網絡上的數據反饋到現實世界。
  • 發力「保險+智能科技」,險企加速線上化-時代財經-北方網
    富德生命人壽的客戶劉小姐想要查詢保單現價，她撥通了客服熱線95535，電話那頭傳來系統智能處理的女聲，劉小姐回應：「現價查詢。」隨後，劉小姐根據女聲的指引在手機上輸入證件號碼，查到了自己的保單現價。　　這是近日發生在95535智能語音導航系統上線後的一幕。今年來，疫情倒逼險企紛紛進行線上化轉型。
  • 商務白話「智能合約」
    所有不包含人類情感、好惡、審美等主觀因素的、可用數學抽象的可計算問題，都能通過圖靈機來運算。逆否命題就是，圖靈機沒法運算的問題，都是不可計算問題，也就是人類通過筆和紙在人腦控制下無法計算的問題。　　從以太坊開始，智能合約便採用圖靈完備的腳本語言來控制、描述業務邏輯。理論上講，一切可以用數學模型抽象為可計算問題的業務場景都能用智能合約來描述和實現。
  • DAC多元量子智能合約預言機 虛擬及現實世界的橋梁
    區塊鏈最大的核心創新在於去中心化的解決信任問題，不需要再去信任和依靠第三方機構的情況下進行價值轉移。其中，智能合約起到了重要的作用。它是一套數字形式定義的合約，幫助合約參與方執行完成任務的協議，節省了時間和繁瑣的步驟。然而智能合約存在外部數據的交互需求，這就使得區塊鏈無法獲取現實世界的數據！預言機至此進入了人們的視野。
  • 3分鐘了解它的保險協議Umbrella Protocol
    縱觀DeFi的歷史，智能合約的開發一直面臨著威脅，快速的發展及可組合性表明，單靠審計並不能保證安全性。目前，智能合約保護的需求，無論是在覆蓋方面還是創新方面，都沒有得到充分的滿足。而最近一系列的DeFi黑客攻擊事件，強調了生態系統需要新的風險管理解決方案。
  • MMMDeFi(MDF)智能合約到底是什麼
    MMMDeFi是MMM去中心化互助金/融的簡稱DeFi是Decentralized Financial詞彙的縮寫 M 是MMM名稱首字母的縮寫 D 是Decentralized一詞首字母縮寫 F 是Financial一詞首字母縮寫
  • 大商所發布聚丙烯、聚氯乙烯和線型低密度聚乙烯期權合約及參數
    期權合約方面，大商所交易部負責人表示，在設計論證3個化工期權合約及參數時，大商所與相關產業企業進行了充分溝通交流，5月25日起向市場公開徵求意見。總體上，市場各方認為3個化工期權的合約條款設計合理、貼近實際，便於理解和操作。因此，此次正式公布的3個化工期權合約與徵求意見的方案保持一致。
  • 零時科技丨CTF技能寶典之智能合約 薅羊毛漏洞
    前言近年來，各個大型CTF（Capture The Flag，中文一般譯作奪旗賽，在網絡安全領域中指的是網絡安全技術人員之間進行技術競技的一種比賽形式）比賽中都有了區塊鏈攻防的身影，而且出現的題目絕大多數都是區塊鏈智能合約攻防。此系列文章我們主要以智能合約攻防為中心，來剖析智能合約攻防的要點，前兩篇我們分享了合約反編譯，反彙編的基礎內容。
  • IMU PLUS引領行業新風向 全方位保障智能合約安全
    1.0數字貨幣時代是被稱為「全球帳簿」，那麼區塊鏈2.0則是一臺「全球計算機」，它是對全球範圍內的市場去中心化。區塊鏈2.0時代被定義為數字貨幣與智能合約的疊加，這時候區塊鏈技術在金融行業的應用達到廣泛場景化及流程化升級，其中以智能合約為代表。
  • STD-Chain——以太坊智能合約Solidity以及IPFS星際文件協議
    STD-Chain參考DPOS+BTF共識機制的優點，獨創了POFProofoffaith（信仰證明機制）讓STD-Chain網絡能超高速運轉，避免區塊網絡擁堵，安全高效的交易確認；此外，STD-Chain還通過兼容以太坊智能合約Solidity以及IPFS星際文件協議,來實現穩定,更具可擴展性以及更開放的區塊鏈應用系統構建。
  • Komosa新時代下 全球第一個波場智能合約營銷矩陣
    Komosa是全球分散生態系統的國際社會，也是有史以來第一個波場智能合約營銷矩陣。這是一種自執行的智能合約 算法，可在一定條件下(矩陣營銷計劃)執行在社區成員之間分配合作夥伴獎 勵的功能。合同代碼是公開可用的。有關交易的信息始終可以在連結 https://tronscan.io上查看。
  • 希臘神話-卡俄斯智能合約的安全性如何考證,技術大神解讀
    在開始之前，要先了解智能合約的地址是怎麼產生的，大家都知錢包地址是通過助記詞生成私鑰，然後通過私鑰生成地址的，每個錢包地址都有一個唯一對應的私鑰，這個私鑰可以操控這個地址裡面所有的資產。，我們知道了【智能合約的地址並不是通過私鑰來生成的】，也就是說這個地址的私鑰即使對於合約的創建者都沒有辦法知道，因為我們沒有辦法通過地址反向推導出私鑰。
  • Injective 正式推出去中心化交割合約
    我們很高興宣布正式推出 Injective 去中心化交割合約市場。這意味著從本周開始，Solstice Pro 測試網將能夠提供新交易市場（例如股票），來幫助擴展 Injective 的無限制的交易市場。
  • 擁有智能合約的比特幣網絡—RSK
    打開APP 擁有智能合約的比特幣網絡—RSK 發表於 2019-07-04 10:32:32 因此RSK作為BTC的側鏈加入了新的轉帳速度認證和BTC智能合約系統。 1.RSK整合了圖靈智能合約，為比特幣加入了智能合約，並且為整個網絡提供了更快的交易速度。比特幣將跨入一個新的轉帳紀元。 2.RSK每秒處理300筆交易，20秒內幾乎可以確認所有的交易。並且RSK使用和BTC一樣的挖礦機制。
  • 星球首發 | AVATAR Network完成千萬元天使輪融資,想建「去中心化...
    在傳統的在線人力資源場景中，數據由中心化機構壟斷，用人單位招聘成本高，求職者隱私洩露、數據篡改等皆為傳統中心化人力機構的痛點。AVATAR Network則希望通過以去中心化的方式存儲職業身份數據，實現一個「去中心化的實名職業身份網絡」，同時嘗試解決數據安全性和真實性問題。