Pencelupan dalam pengembangan pada Ethereum. Bagian 5: Oraclize

Akses ke file besar dan berbagai data dinamis eksternal seringkali merupakan bagian yang sangat penting dari aplikasi yang didesentralisasi. Pada saat yang sama, Ethereum sendiri tidak menyediakan mekanisme untuk berbelok ke luar - kontrak pintar hanya dapat dibaca dan ditulis dalam blockchain itu sendiri. Pada artikel ini, kami akan mempertimbangkan Oraclize, yang hanya memungkinkan untuk berinteraksi dengan dunia luar dengan menanyakan hampir semua sumber daya Internet. Topik terkait adalah IPFS, dan menyebutkannya secara singkat.

IPFS

IPFS adalah sistem file terdistribusi dengan pengalamatan konten. Ini berarti bahwa untuk konten file apa pun yang ditambahkan di sana, hash unik dipertimbangkan. Hash yang sama kemudian digunakan untuk mencari dan mengambil konten ini dari jaringan.
Informasi dasar telah dijelaskan dalam artikel ini dan beberapa lainnya, jadi kami tidak melihat alasan untuk mengulanginya.

Mengapa menggunakan IPFS bersamaan dengan Ethereum?

Untuk menyimpan konten volume apa pun di blockchain terlalu mahal dan berbahaya bagi jaringan. Oleh karena itu, opsi terbaik adalah menyimpan beberapa jenis tautan ke file yang terletak di penyimpanan off-chain, belum tentu IPFS. Tetapi IPFS memiliki sejumlah keunggulan:

• Tautan file adalah hash yang unik untuk konten spesifik file, jadi jika kita meletakkan hash ini di blockchain, kita dapat yakin bahwa file yang diterima darinya adalah yang awalnya ditambahkan, file tidak dapat diganti
• Sistem terdistribusi menjamin terhadap tidak tersedianya server tertentu (karena pemblokiran atau alasan lain)
• Tautan ke file dan konfirmasi hash digabungkan dalam satu baris, yang berarti Anda dapat menulis lebih sedikit ke blockchain dan menghemat bensin

Di antara kekurangannya, orang dapat menyebutkan bahwa karena tidak ada server pusat, maka untuk aksesibilitas file perlu bahwa setidaknya satu file "didistribusikan". Tetapi jika Anda memiliki file tertentu, maka menghubungkan ke distributor itu mudah - mulai daemon ipfs Anda dan tambahkan file melalui ipfs add .

Teknologi ini sangat cocok untuk ideologi desentralisasi, oleh karena itu, mengingat Oraclize sekarang, kita akan sering menghadapi penggunaan IPFS dalam mekanisme oracle yang berbeda.

Oraclize

Untuk melakukan hampir semua pekerjaan yang bermanfaat, kontrak yang cerdas perlu menerima data baru. Namun, tidak ada kemampuan bawaan untuk memenuhi permintaan dari blockchain ke dunia luar. Tentu saja, Anda dapat menambahkan semua yang diperlukan oleh transaksi secara manual, tetapi tidak mungkin untuk memverifikasi dari mana data ini berasal dan keandalannya. Plus, Anda mungkin perlu mengatur infrastruktur tambahan untuk memperbarui data dinamis dengan cepat, seperti nilai tukar. Dan pembaruan dengan interval tetap akan menyebabkan kelebihan gas.

Oleh karena itu, layanan yang disediakan oleh Oraclize sangat berguna: dalam kontrak pintar, Anda dapat mengirim permintaan ke hampir semua API atau sumber daya di Internet, pastikan bahwa data yang diterima dari sumber daya yang ditentukan tidak berubah, dan gunakan hasilnya dalam kontrak pintar yang sama.

Oraclize bukan hanya layanan Ethereum, fungsionalitas serupa disediakan untuk blockchain lainnya, tetapi kami hanya akan menjelaskan bundel dengan Ethereum.

Memulai

Semua yang diperlukan untuk memulai adalah menambahkan salah satu file oraclizeAPI dari repositori ke proyek. Anda hanya perlu memilih yang cocok untuk versi kompiler Anda (solc): oraclizeAPI_0.5.sol untuk versi mulai dari 0.4.18, oraclizeAPI_0.4.sol untuk versi dari 0.4.1, oraclizeAPI_pre0.4.sol untuk semua yang lebih tua, dukungan Versi ini sudah dihentikan. Jika Anda menggunakan truffle, maka jangan lupa untuk mengganti nama file menjadi usingOraclize - ini mengharuskan nama file dan kontrak yang cocok.

Dengan memasukkan file yang sesuai dalam proyek Anda, Anda mewarisi kontrak dari usingOraclize . Dan Anda dapat mulai menggunakan Oracle, yang bermuara pada dua hal utama: mengirim permintaan menggunakan penolong oraclize_query , dan kemudian memproses hasilnya dalam fungsi __callback . Kontrak pintar paling sederhana (untuk mendapatkan harga airtime saat ini dalam dolar) mungkin terlihat seperti ini:

 pragma solidity 0.4.23; import "./usingOraclize.sol"; contract ExampleContract is usingOraclize { string public ETHUSD; event updatedPrice(string price); event newOraclizeQuery(string description); function ExampleContract() payable { updatePrice(); } function __callback(bytes32 myid, string result) { require (msg.sender == oraclize_cbAddress()); ETHUSD = result; updatedPrice(result); } function updatePrice() payable { if (oraclize_getPrice("URL") > this.balance) { newOraclizeQuery("Oraclize query was NOT sent, please add some ETH to cover for the query fee"); } else { newOraclizeQuery("Oraclize query was sent, standing by for the answer.."); oraclize_query("URL", "json(https://api.coinmarketcap.com/v1/ticker/ethereum/?convert=USD).0.price_usd"); } } } 

Fungsi mengirim permintaan adalah updatePrice . Anda dapat melihat bahwa pertama-tama ada cek bahwa oraclize_getPrice(“URL”) lebih besar dari saldo kontrak saat ini. Ini karena panggilan oraclize_query harus dibayar, harga dihitung sebagai jumlah dari komisi tetap dan pembayaran gas untuk menelepon kembali. “URL” adalah sebutan dari salah satu jenis sumber data, dalam hal ini adalah permintaan sederhana melalui https, maka kami akan mempertimbangkan opsi lain. Jawaban berdasarkan permintaan dapat diuraikan di muka sebagai json (seperti dalam contoh) dan dalam beberapa cara lain (kami akan mempertimbangkan lebih lanjut). Baris __callback dikembalikan dalam __callback . Pada awalnya, diverifikasi bahwa panggilan tersebut dilewatkan dari alamat tepercaya oraclize

Semua opsi untuk menggunakan oraclize dibangun berdasarkan satu skema, hanya sumber data dan kemampuan untuk menambahkan otentikasi ke __callback . Oleh karena itu, dalam contoh di masa mendatang kami hanya akan mengutip perbedaan yang signifikan.

Gunakan harga

Seperti yang telah disebutkan, eter ekstra dibayarkan untuk permintaan oraclize, dan itu dihapus dari saldo kontrak, dan bukan alamat panggilan. Pengecualian hanya permintaan pertama dari setiap kontrak baru, itu diberikan secara gratis. Menarik juga bahwa mekanisme yang sama dipertahankan dalam jaringan uji, tetapi pembayaran dilakukan dengan menyiarkan jaringan yang sesuai, yaitu, dalam permintaan testnet praktis gratis.

Telah disebutkan bahwa harga permintaan terdiri dari dua nilai: komisi tetap dan pembayaran untuk panggilan balik gas. Komisi tetap didefinisikan dalam dolar, dan jumlah eter dihitung dari kurs saat ini. Komisi tergantung pada sumber data dan mekanisme pendukung tambahan, yang akan kita bahas. Tabel harga saat ini terlihat seperti ini:


Seperti yang Anda lihat, harga per permintaan URL adalah beberapa sen. Apakah banyak atau sedikit? Untuk melakukan ini, mari kita pertimbangkan berapa biaya bagian kedua - biaya gas panggilan balik.
Ini bekerja sesuai dengan skema berikut: jumlah eter yang dibutuhkan untuk membayar jumlah gas tetap pada harga tetap ditransfer terlebih dahulu dengan permintaan dari kontrak. Jumlah ini harus cukup untuk membuat panggilan balik, dan harganya harus memadai untuk pasar, jika tidak transaksi tidak akan melalui atau akan menggantung untuk waktu yang sangat lama. Pada saat yang sama, jelas bahwa tidak selalu mungkin untuk mengetahui jumlah gas di muka, oleh karena itu, dewan harus memiliki margin (margin tidak dikembalikan). Nilai standarnya adalah batas 200 ribu gas dengan harga 20 gwei. Ini cukup untuk panggilan balik rata-rata dengan beberapa entri dan semacam logika. Dan harga 20 gwei, meskipun mungkin tampak terlalu besar pada saat ini (pada saat penulisan, rata-rata adalah 4 gwei), tetapi pada saat masuknya transaksi, harga pasar tiba-tiba bisa melompat dan bahkan lebih tinggi, sehingga secara umum nilai-nilai ini dekat dengan yang sebenarnya digunakan. Jadi, dengan nilai-nilai seperti itu dan harga udara di wilayah $ 500, pembayaran gas akan mendekati $ 2, jadi kita dapat mengatakan bahwa komisi tetap memakan sebagian kecil.

Jika Anda tahu apa yang Anda lakukan, maka ada opsi untuk mengubah batas dan harga gas, sehingga menghemat permintaan secara signifikan.

Harga gas dapat diatur oleh fungsi terpisah - oraclize_setCustomGasPrice(< wei>) . Setelah panggilan, harga disimpan dan digunakan dalam semua permintaan berikutnya.
Batas itu dapat diatur dalam kueri oraclize_query , menetapkannya dengan argumen terakhir, misalnya seperti ini:

 oraclize_query("URL", "<>", 50000); 

Jika Anda memiliki logika kompleks dalam __callback dan gas dikonsumsi lebih dari 200rb, maka Anda pasti perlu menetapkan batas yang mencakup kasus konsumsi gas terburuk. Kalau tidak, jika batas terlampaui, __callback hanya __callback memutar kembali.

Ngomong-ngomong, baru-baru ini oraclize mendapatkan informasi yang dapat Anda bayar untuk permintaan di luar blockchain, yang akan memungkinkan Anda untuk tidak menghabiskan seluruh batas atau mengembalikan saldo (dan pembayaran tidak datang dari kontrak). Kami belum harus menggunakan ini, tetapi oraclize penawaran untuk menghubungi mereka di info@oraclize.it, jika opsi ini menarik. Karena itu, perlu diingat.

Bagaimana cara kerjanya

Mengapa, setelah mewarisi dari kontrak pintar biasa, apakah kita mendapatkan fungsionalitas yang pada awalnya tidak didukung oleh mekanisme blockchain? Bahkan, layanan oracle tidak hanya terdiri dari kontrak dengan fungsi pembantu. Pekerjaan utama untuk mendapatkan data dilakukan oleh layanan eksternal. Kontrak pintar membentuk aplikasi untuk akses ke data eksternal dan menempatkannya di blockchain. Layanan eksternal - memonitor blok-blok baru dari blockchain dan, jika mendeteksi suatu aplikasi, mengeksekusinya. Secara skematis, ini dapat direpresentasikan sebagai berikut:

Sumber data

Selain URL dipertimbangkan, oraclize menyediakan 4 opsi lagi (yang Anda lihat di bagian penetapan harga): WolframAlpha , IPFS , random dan computation . Mari kita pertimbangkan masing-masing.

1. URL

Contoh sudah dibahas menggunakan sumber data ini. Ini adalah sumber permintaan HTTP ke berbagai API. Contohnya adalah sebagai berikut:

 oraclize_query("URL", "json(https://api.coinmarketcap.com/v1/ticker/ethereum/?convert=USD).0.price_usd"); 

Ini mendapatkan harga eter, dan karena api menyediakan string json dengan kumpulan data, permintaan tersebut dibungkus dengan parser json dan hanya mengembalikan bidang yang kita butuhkan. Dalam hal ini, GET, tetapi URL sumber juga mendukung permintaan POST. Jenis permintaan ditentukan secara otomatis oleh argumen tambahan. Jika ada json yang valid seperti pada contoh ini:

 oraclize_query("URL", "json(https://shapeshift.io/sendamount).success.deposit", '{"pair":"eth_btc","amount":"1","withdrawal":"1AAcCo21EUc1jbocjssSQDzLna9Vem2UN5"}') 

maka permintaan diproses sebagai POST (api yang digunakan dijelaskan di sini , jika tertarik)

2. WolframAlpha

Sumber data ini memungkinkan Anda untuk mengakses layanan WolframAlpha , yang dapat memberikan jawaban atas berbagai permintaan fakta atau perhitungan, misalnya

 oraclize_query(“WolframAlpha”, “president of Russia”) 

akan mengembalikan Vladimir Putin , dan meminta

 oraclize_query(“WolframAlpha”, “solve x^2-4”) 

akan mengembalikan x = 2 .
Seperti yang Anda lihat, hasilnya tidak lengkap karena simbol ± hilang. Karena itu, sebelum menggunakan sumber ini, Anda perlu memeriksa bahwa nilai permintaan tertentu dapat digunakan dalam kontrak pintar. Selain itu, otentikasi tidak didukung untuk tanggapan, jadi oraclize sendiri merekomendasikan agar sumber ini hanya digunakan untuk pengujian.

3. IPFS

Seperti yang Anda tebak, ini memungkinkan Anda untuk mengambil konten file di IPFS menggunakan multi-hash. Batas waktu untuk menerima konten adalah 20 detik.

 oraclize_query(“IPFS”, “QmTL5xNq9PPmwvM1RhxuhiYqoTJcmnaztMz6PQpGxmALkP”) 

akan kembali Hello, Habr! (jika file dengan konten ini masih tersedia)

4. acak

Pembuatan angka acak bekerja dengan cara yang sama dengan sumber lain, tetapi jika Anda menggunakan oraclize_query , dibutuhkan persiapan argumen yang memakan waktu. Untuk menghindari hal ini, Anda dapat menggunakan oraclize_newRandomDSQuery(delay, nbytes, customGasLimit) pembantu oraclize_newRandomDSQuery(delay, nbytes, customGasLimit) , mengatur hanya penundaan eksekusi (dalam detik), jumlah byte yang dihasilkan dan batas gas untuk memanggil __callback .
Menggunakan random memiliki beberapa hal yang perlu diingat:

• Untuk mengkonfirmasi bahwa nomor tersebut sebenarnya acak, jenis verifikasi khusus digunakan - Buku Besar, yang dapat dilakukan pada blockchain (tidak seperti orang lain, tetapi lebih lanjut tentang itu nanti). Ini berarti bahwa dalam konstruktor kontrak pintar, Anda perlu mengatur metode verifikasi ini berdasarkan fungsinya:
  
  

   oraclize_setProof(proofType_Ledger); 

  
  Dan di awal panggilan balik harus ada cek itu sendiri:
  
  

    function __callback(bytes32 _queryId, string _result, bytes _proof) { require (oraclize_randomDS_proofVerify__returnCode(_queryId, _result, _proof) == 0) ); <...> 

  
  Pemeriksaan ini memerlukan jaringan nyata dan tidak akan bekerja pada Ganache, jadi untuk pengujian lokal Anda dapat menghapus sementara garis ini. Omong-omong, argumen ketiga untuk __callback sini adalah parameter opsional _proof . Itu selalu diperlukan ketika salah satu jenis konfirmasi digunakan.
• Jika Anda menggunakan nomor acak untuk saat-saat kritis, misalnya, untuk menentukan pemenang dalam lotre, tangkap input pengguna sebelum mengirimRandomDSQuery baru. Kalau tidak, situasi ini dapat terjadi: oraclize panggilan _callback dan transaksi terlihat oleh semua orang dalam daftar yang tertunda. Bersamaan dengan ini, angka acak itu sendiri terlihat. Jika pengguna dapat melanjutkan, secara kasar, untuk membuat taruhan, maka mereka akan dapat menentukan harga gas yang lebih tinggi dan mendorong tarif mereka sebelum _callback dijalankan, mengetahui sebelumnya bahwa itu akan menang.

5. perhitungan

Ini adalah sumber yang paling fleksibel. Ini memungkinkan Anda untuk menulis skrip Anda sendiri dan menggunakannya sebagai sumber data. Komputasi terjadi pada AWS. Untuk eksekusi, Anda perlu mendeskripsikan Dockerfile dan menggabungkannya dengan file tambahan sewenang-wenang dalam arsip zip, dan mengunduh arsip di IPFS. Implementasi harus memenuhi ketentuan berikut:

• Tulis jawaban yang ingin Anda kembalikan dengan baris terakhir di stdout
• Jawabannya tidak boleh lebih dari 2500 karakter
• Inisialisasi dan eksekusi tidak boleh lebih dari 5 menit total

Sebagai contoh bagaimana hal ini dilakukan, kami akan mempertimbangkan bagaimana melakukan penyatuan paling sederhana dari baris yang ditransmisikan dan mengembalikan hasilnya.

Dockerfile:

 FROM ubuntu:16.04 MAINTAINER "info@rubyruby.ru" CMD echo "$ARG0 $ARG1 $ARG2 $ARG3" 

Variabel lingkungan ARG0 , ARG1 , dll. - Ini adalah parameter yang diteruskan bersama dengan permintaan.
Tambahkan dockerfile ke arsip, mulai server ipfs dan tambahkan arsip ini di sana

 $ zip concatenation.zip Dockerfile $ ipfs daemon & $ ipfs add concatenation.zip QmWbnw4BBFDsh7yTXhZaTGQnPVCNY9ZDuPBoSwB9A4JNJD 

Kami menggunakan hash yang dihasilkan untuk mengirim permintaan melalui oraclize_query dalam kontrak pintar:

 oraclize_query("computation", ["QmVAS9TNKGqV49WTEWv55aMCTNyfd4qcGFFfgyz7BYHLdD", "s1", "s2", "s3", "s4"]); 

Array digunakan sebagai argumen, di mana elemen pertama adalah multihash arsip, dan sisanya adalah parameter yang termasuk dalam variabel lingkungan.

Jika Anda menunggu permintaan selesai, maka __callback akan __callback hasilnya s1 s2 s3 s4 .

Pembantu Parser dan Subqueries

Dari respons yang dikembalikan oleh sumber apa pun, Anda dapat memilih sebelumnya hanya informasi yang diperlukan menggunakan sejumlah pembantu, seperti:

1. JSON parser

Anda melihat metode ini dalam contoh pertama, di mana hanya harga dikembalikan dari hasil yang dikembalikan oleh coinmarketcap:

 json(https://api.coinmarketcap.com/v1/ticker/ethereum/?convert=USD).0.price_usd 

Kasingnya cukup jelas, contohnya kembali:

 [ { "id": "ethereum", "name": "Ethereum", "symbol": "ETH", "rank": "2", "price_usd": "462.857", "price_btc": "0.0621573", "24h_volume_usd": "1993200000.0", "market_cap_usd": "46656433775.0", "available_supply": "100800968.0", "total_supply": "100800968.0", "max_supply": null, "percent_change_1h": "-0.5", "percent_change_24h": "-3.02", "percent_change_7d": "5.93", "last_updated": "1532064934" } ] 

Karena ini adalah array, kami mengambil elemen 0 , dan dari sana - bidang price_usd

2. XML

Penggunaannya mirip dengan JSON, misalnya:

 xml(https://informer.kovalut.ru/webmaster/getxml.php?kod=7701).Exchange_Rates.Central_Bank_RF.USD.New.Exch_Rate 

3. HTML

Anda dapat menguraikan XHTML menggunakan XPath. Misalnya, dapatkan kapitalisasi pasar dengan etherscan:

 html(https://etherscan.io/).xpath(string(//*[contains(@href, '/stat/supply')]/font)) 

MARKET CAP OF $46.148 BillionB

4. Pembantu Biner

Memungkinkan Anda memotong potongan dari data mentah menggunakan fungsi slice (offset, length). Misalnya, kami memiliki file dengan konten "abc":

 echo "abc" > example.bin 

Letakkan di IPFS:

 $ ipfs add example.bin added Qme4u9HfFqYUhH4i34ZFBKi1ZsW7z4MYHtLxScQGndhgKE 

Sekarang potong 1 karakter dari tengah:

 binary(Qme4u9HfFqYUhH4i34ZFBKi1ZsW7z4MYHtLxScQGndhgKE).slice(1, 1) 

Dalam jawaban yang kita dapatkan b

Seperti yang mungkin Anda perhatikan, dalam kasus pembantu biner, bukan sumber IP yang digunakan, tetapi IPFS. Bahkan, parser dapat diterapkan ke sumber apa pun, katakanlah JSON tidak perlu menerapkan apa yang mengembalikan URL, Anda dapat menambahkan konten tersebut ke file:

 { "one":"1", "two":"2" } 

Tambahkan ke IPFS:

 $ ipfs add test.json added QmZinLwAq5fy4imz8ZNgupWeNFTneUqHjPiTPX9tuR7Vxp 

Dan kemudian bongkar seperti ini:

 json(QmZinLwAq5fy4imz8ZNgupWeNFTneUqHjPiTPX9tuR7Vxp).one 

Kami mendapat 1

Dan kasus penggunaan yang sangat menarik adalah menggabungkan sumber data dan pengurai dalam satu permintaan. Ini dimungkinkan menggunakan sumber data nested terpisah. Kami menggunakan file yang baru saja kami buat dalam permintaan yang lebih kompleks (menambahkan nilai dalam dua bidang):

 [WolframAlpha] add ${[IPFS] json(QmZinLwAq5fy4imz8ZNgupWeNFTneUqHjPiTPX9tuR7Vxp).one} to ${[IPFS] json(QmZinLwAq5fy4imz8ZNgupWeNFTneUqHjPiTPX9tuR7Vxp).two} 

Kami mendapat 3
Permintaan dibentuk sebagai berikut: tentukan sumber data nested , lalu untuk setiap permintaan tambahkan nama sumber di depannya dalam kurung siku, dan tambahan bingkai semua subqueries dalam ${..} .

Pengujian

Oraclize menyediakan layanan validasi kueri yang berguna tanpa perlu kontrak pintar. Cukup masuk, pilih sumber data, metode verifikasi dan Anda dapat melihat bahwa itu akan kembali ke __callback jika Anda mengirim permintaan yang sesuai

Untuk verifikasi lokal bersamaan dengan kontrak pintar, Anda dapat menggunakan versi khusus dari Remix IDE yang mendukung permintaan oraclize.

Dan untuk mengecek secara lokal dengan Ganache, Anda akan memerlukan ethereum bridge , yang akan menggunakan oraclize kontrak pintar ke testnet Anda. Untuk pengujian, pertama-tama tambahkan baris berikut ke konstruktor kontrak Anda:

 OAR = OraclizeAddrResolverI(0x6f485C8BF6fc43eA212E93BBF8ce046C7f1cb475); 

lari

 ganache-cli 

Lalu

 node bridge --dev 

Tunggu sampai kontraknya mati dan Anda dapat menguji. Dalam output dari node bridge Anda dapat melihat permintaan yang dikirim dan respons yang diterima.

Bantuan lain tidak hanya selama pengujian, tetapi juga dalam penggunaan aktual adalah kemampuan untuk memonitor permintaan di sini . Jika Anda meminta pada jaringan publik, maka Anda dapat menggunakan hash dari transaksi di mana permintaan dieksekusi. Jika Anda menggunakan otentikasi, maka perlu diingat bahwa mereka dijamin akan dikirim hanya ke mainnet, untuk jaringan lain dapat mengembalikan 0. Jika permintaan berada di jaringan lokal, Anda dapat menggunakan id permintaan, yang mengembalikan oraclize_query . Ngomong-ngomong, disarankan untuk selalu menyimpan id ini, misalnya, dalam pemetaan serupa:

 mapping(bytes32=>bool) validIds; 

Pada saat permintaan, tandai id yang dikirim sebagai true :

 bytes32 queryId = oraclize_query(<...>); validIds[queryId] = true; 

Dan kemudian di __callback periksa bahwa permintaan dengan id ini belum diproses:

 function __callback(bytes32 myid, string result) { require(validIds[myid] != bytes32(0)); require(msg.sender == oraclize_cbAddress()); validIds[myid] = bytes32(0); <...> 

Ini diperlukan karena __callback pada satu permintaan dapat dipanggil lebih dari sekali karena kekhasan mekanisme Oraclize.

Otentikasi

Di tabel dengan sumber, Anda dapat melihat bahwa sumber yang berbeda dapat mendukung berbagai jenis konfirmasi, dan biaya yang berbeda mungkin dibebankan. Ini adalah bagian yang sangat penting dari oraclize, tetapi deskripsi rinci tentang mekanisme ini adalah topik yang terpisah.

Mekanisme yang paling umum digunakan, setidaknya oleh kami, adalah TLSNotary dengan penyimpanan di IPFS. Penyimpanan di IPFS lebih efisien karena __callback tidak mengembalikan bukti itu sendiri (mungkin di wilayah 4-5 kilobyte), tetapi multi-hash yang jauh lebih kecil. Untuk menentukan tipe ini, tambahkan baris dalam konstruktor:

 oraclize_setProof(proofType_TLSNotary | proofStorage_IPFS); 

Kita hanya dapat mengatakan bahwa tipe ini, secara kasar, melindungi kita dari ketidakakuratan data yang diterima dari Oraclize. Tetapi Oraclize menggunakan server Amazon, yang bertindak sebagai auditor, sehingga mereka hanya harus percaya.

Baca lebih lanjut di sini .

Kesimpulan

Oraclize menyediakan alat yang secara signifikan meningkatkan jumlah kasus penggunaan untuk kontrak pintar, serta IPFS, yang dapat dilihat di beberapa versi permintaan Oracle. Masalah utama adalah bahwa kita lagi menggunakan data eksternal yang tunduk pada ancaman yang seharusnya dilindungi oleh blockchain: sentralisasi, kemampuan memblokir, perubahan kode, spoofing. Tetapi sementara ini semua tidak terhindarkan, dan opsi untuk memperoleh data sangat berguna dan layak, Anda hanya perlu menyadari mengapa penggunaan blockchain diperkenalkan ke dalam proyek dan apakah penggunaan sumber eksternal yang tidak dipercaya mengurangi manfaat menjadi nol.

Jika Anda tertarik pada beberapa topik pengembangan pada Ethereum yang belum diungkapkan dalam artikel ini - tulis di komentar, mungkin kami akan membahasnya di berikut ini.

Pencelupan dalam pengembangan pada Ethereum:
Bagian 1: Pendahuluan
Bagian 2: Web3.js dan gas
Bagian 3: aplikasi pengguna
Bagian 4: deploy dan debug di truffle, ganache, infura