Scaling Blockchains With Off-chain Data

Diterbitkan Ulang Oleh Plato

Followers: 0

Saat hash bernilai sejuta kata

Sekarang sudah jelas bahwa banyak kasus penggunaan blockchain tidak ada hubungannya dengan transaksi keuangan. Alih-alih, tujuan rantai adalah untuk memungkinkan agregasi, pemesanan, cap waktu, dan pengarsipan yang terdesentralisasi Apa pun jenis informasi, termasuk data terstruktur, korespondensi atau dokumentasi. Nilai inti blockchain memungkinkan para pesertanya untuk secara terbukti dan permanen menyetujui dengan tepat data apa yang dimasukkan, kapan dan oleh siapa, tanpa bergantung pada perantara tepercaya. Misalnya, SAP baru saja diluncurkan platform blockchain, yang mendukung MultiChain dan Hyperledger Fabric, menargetkan berbagai rantai pasokan dan aplikasi non-keuangan lainnya.

Cara termudah untuk menggunakan blockchain untuk merekam data adalah dengan menyematkan setiap bagian data langsung di dalam transaksi. Setiap transaksi blockchain ditandatangani secara digital oleh satu atau lebih pihak, direplikasi ke setiap node, dipesan dan diberi stempel waktu oleh algoritma konsensus rantai, dan disimpan secara permanen dengan cara yang tidak dapat dirusak. Oleh karena itu, setiap data dalam transaksi akan disimpan secara identik tetapi independen oleh setiap node, bersama dengan bukti siapa yang menulisnya dan kapan. Pengguna rantai dapat mengambil informasi ini kapan saja.

Misalnya, MultiChain 1.0 mengizinkan satu atau lebih "aliran" yang diberi nama untuk dibuat di blockchain dan kemudian digunakan untuk menyimpan dan mengambil data mentah. Setiap aliran memiliki kumpulan izin tulisnya sendiri, dan setiap node dapat dengan bebas memilih aliran mana yang akan dilanggan. Jika node berlangganan streaming, node tersebut mengindeks konten streaming tersebut secara real-time, memungkinkan item diambil dengan cepat berdasarkan pemesanan, stempel waktu, nomor blok, atau alamat penerbit, serta melalui "kunci" (atau label) dimana item dapat diberi tag. MultiChain 2.0 (sejak alpha 1) memperluas streaming untuk mendukung teks Unicode atau data JSON, serta beberapa kunci per item dan beberapa item per transaksi. Ini juga menambahkan fungsi peringkasan seperti "JSON merge" yang menggabungkan item dengan kunci atau penerbit yang sama dengan cara yang berguna.

Kerahasiaan dan skalabilitas

Meskipun menyimpan data secara langsung di blockchain berfungsi dengan baik, ia mengalami dua kekurangan utama - kerahasiaan dan skalabilitas. Untuk memulai dengan kerahasiaan, konten setiap item aliran dapat dilihat oleh setiap node di rantai, dan ini belum tentu merupakan hasil yang diinginkan. Dalam banyak kasus, sepotong data hanya boleh terlihat oleh subset node tertentu, meskipun node lain diperlukan untuk membantu pengurutan, timestamping, dan notarisasinya.

Kerahasiaan adalah masalah yang relatif mudah dipecahkan, dengan mengenkripsi informasi sebelum dimasukkan ke dalam transaksi. Kunci dekripsi untuk setiap bagian data hanya dibagikan dengan peserta yang dimaksudkan untuk melihatnya. Pengiriman kunci dapat dilakukan secara on-chain menggunakan kriptografi asimetris (as dijelaskan di sini) atau melalui mekanisme off-chain, seperti yang lebih disukai. Setiap node yang tidak memiliki kunci untuk mendekripsi suatu item tidak akan melihat lebih dari omong kosong biner.

Skalabilitas, di sisi lain, merupakan tantangan yang lebih signifikan. Katakanlah bahwa platform blockchain yang layak harus mendukung throughput jaringan 500 transaksi per detik. Jika tujuan rantai adalah penyimpanan informasi, maka ukuran setiap transaksi akan bergantung terutama pada seberapa banyak data yang dikandungnya. Setiap transaksi juga akan membutuhkan (setidaknya) 100 byte overhead untuk menyimpan alamat pengirim, tanda tangan digital, dan beberapa bit dan potongan lainnya.

Jika kita mengambil kasus yang mudah, di mana setiap item adalah struktur JSON kecil 100 byte, throughput data keseluruhan akan menjadi 100 kilobyte per detik, dihitung dari 500 × (100 + 100). Ini berarti bandwidth di bawah 1 megabit / detik, yang secara nyaman berada dalam kapasitas koneksi Internet modern mana pun. Data akan terakumulasi dengan kecepatan sekitar 3 terabyte per tahun, yang merupakan jumlah yang tidak sedikit. Tetapi dengan hard drive 12 terabyte sekarang tersedia secara luas, dan RAID pengontrol yang menggabungkan beberapa drive fisik menjadi satu drive logis, kami dapat dengan mudah menyimpan 10-20 tahun data pada setiap node tanpa terlalu banyak kerumitan atau biaya.

Namun, semuanya akan terlihat sangat berbeda jika kita menyimpan informasi yang lebih besar, seperti dokumentasi yang dipindai. Pindaian JPEG berkualitas wajar dari selembar kertas A4 mungkin berukuran 500 kilobyte. Kalikan ini dengan 500 transaksi per detik, dan kita melihat throughput 250 megabita per detik. Ini berarti bandwidth 2 gigabit / detik, yang lebih cepat daripada kebanyakan jaringan lokal, apalagi koneksi ke Internet. Di Amazon Web Services 'termurah harga terbitan sebesar $ 0.05 per gigabyte, itu berarti tagihan bandwidth tahunan sebesar $ 400,000 per node. Dan di mana setiap node akan menyimpan 8000 terabyte data baru yang dihasilkan setiap tahun?

Jelas bahwa, untuk aplikasi blockchain yang menyimpan banyak data besar, penyimpanan on-chain langsung bukanlah pilihan praktis. Untuk menambah penghinaan terhadap cedera, jika data dienkripsi untuk menyelesaikan masalah kerahasiaan, node diminta untuk menyimpan sejumlah besar informasi yang bahkan tidak dapat mereka baca. Ini bukanlah proposisi yang menarik bagi peserta jaringan.

Solusi hashing

Jadi bagaimana kita mengatasi masalah skalabilitas data? Bagaimana kita bisa memanfaatkan notarisasi data blockchain yang terdesentralisasi, tanpa mereplikasi data itu ke setiap node di rantai?

Jawabannya adalah dengan teknologi pintar yang disebut "hash". Hash adalah angka panjang (pikirkan 256 bit, atau sekitar 80 digit desimal) yang secara unik mengidentifikasi sepotong data. Hash dihitung dari data menggunakan a fungsi satu arah yang memiliki properti kriptografik penting: Dengan adanya data apa pun, mudah dan cepat untuk menghitung hashnya. Tetapi dengan hash tertentu, secara komputasi tidak mungkin untuk menemukan sepotong data yang akan menghasilkan hash itu. Dan ketika kami mengatakan "secara komputasi tidak layak", yang kami maksud adalah lebih banyak perhitungan daripada jumlah atom di alam semesta yang diketahui.

Hash memainkan peran penting dalam semua blockchain, dengan mengidentifikasi transaksi dan pemblokiran secara unik. Mereka juga mendasari tantangan komputasi dalam sistem bukti kerja seperti bitcoin. Banyak fungsi hash yang berbeda telah dikembangkan, dengan nama gobbledygook seperti BLAKE2, MD5 dan RIPEMD160. Tetapi agar fungsi hash apa pun dapat dipercaya, ia harus menjalani tinjauan dan pengujian akademis yang ekstensif. Tes ini datang dalam bentuk percobaan serangan, seperti "preimage" (menemukan input dengan hash yang diberikan), "second preimage" (menemukan input kedua dengan hash yang sama dengan input yang diberikan) dan "collision" (menemukan dua input berbeda dengan hash yang sama). Bertahan dari tantangan ini jauh dari mudah, dengan sejarah panjang dan tragis dari fungsi hash yang rusak membuktikan pepatah terkenal: "Jangan gunakan crypto Anda sendiri."

Untuk kembali ke masalah awal kita, kita bisa menyelesaikan skalabilitas data di blockchain dengan menyematkan potongan data besar dalam transaksi, bukan datanya sendiri. Setiap hash bertindak sebagai "komitmen" untuk data masukannya, dengan datanya sendiri disimpan di luar blockchain atau "di luar rantai". Misalnya, menggunakan fungsi hash SHA256 yang populer, gambar JPEG 500 kilobyte dapat direpresentasikan dengan angka 32-byte, pengurangan lebih dari 15,000 ×. Bahkan dengan kecepatan 500 gambar per detik, hal ini menempatkan kita kembali dengan nyaman di wilayah persyaratan bandwidth dan penyimpanan yang layak, dalam hal data yang disimpan di rantai itu sendiri.

Tentu saja, setiap peserta blockchain yang membutuhkan gambar off-chain tidak dapat mereproduksinya dari hashnya. Tetapi jika gambar dapat diambil dengan cara lain, hash on-chain berfungsi untuk mengonfirmasi siapa yang membuatnya dan kapan. Sama seperti data on-chain biasa, hash disematkan di dalam transaksi yang ditandatangani secara digital, yang disertakan dalam rangkaian berdasarkan konsensus. Jika file gambar jatuh dari langit, dan hash untuk gambar itu cocok dengan hash di blockchain, maka asal dan stempel waktu gambar itu dikonfirmasi. Jadi, blockchain memberikan nilai yang persis sama dalam hal notaris seolah-olah gambar itu langsung disematkan di rantai.

Sebuah pertanyaan tentang pengiriman

Sejauh ini baik. Dengan menanamkan hash di blockchain alih-alih data asli, kami memiliki solusi mudah untuk masalah skalabilitas. Meskipun demikian, satu pertanyaan penting tetap ada:

Bagaimana cara kami mengirimkan konten off-chain asli ke node yang membutuhkannya, jika tidak melalui chain itu sendiri?

Pertanyaan ini memiliki beberapa kemungkinan jawaban, dan kami tahu pengguna MultiChain menerapkan semuanya. Salah satu pendekatan dasarnya adalah menyiapkan repositori terpusat di beberapa pihak tepercaya, di mana semua data off-chain diunggah kemudian diambil kembali. Sistem ini secara alami dapat menggunakan "pengalamatan konten", yang berarti bahwa hash dari setiap bagian data berfungsi langsung sebagai pengenalnya untuk pengambilan. Namun, meskipun pengaturan ini mungkin berfungsi untuk bukti konsep, itu tidak masuk akal untuk produksi, karena inti dari blockchain adalah untuk menghapus perantara tepercaya. Bahkan jika hash on-chain mencegah perantara dari memalsukan data, itu masih dapat menghapus data atau gagal mengirimkannya ke beberapa peserta, karena kegagalan teknis atau tindakan karyawan yang nakal.

Kemungkinan yang lebih menjanjikan adalah komunikasi point-to-point, di mana node yang membutuhkan beberapa data off-chain memintanya langsung dari node yang menerbitkannya. Ini menghindari mengandalkan perantara tepercaya, tetapi menderita tiga kekurangan alternatif:

Ini membutuhkan peta alamat blockchain ke alamat IP, untuk memungkinkan konsumen dari beberapa data untuk berkomunikasi langsung dengan penerbitnya. Blockchain umumnya dapat menghindari jenis konfigurasi jaringan statis ini, yang dapat menjadi masalah dalam hal failover dan privasi.
Jika node penerbit asli telah meninggalkan jaringan, atau sementara tidak dapat digunakan, maka data tidak dapat diambil oleh orang lain.
Jika sejumlah besar node tertarik pada beberapa data, penerbit akan kewalahan dengan permintaan. Hal ini dapat menyebabkan kemacetan jaringan yang parah, memperlambat sistem penerbit, dan menyebabkan penundaan yang lama bagi mereka yang mencoba mengambil data tersebut.

Untuk menghindari masalah ini, idealnya kami menggunakan semacam mekanisme pengiriman yang terdesentralisasi. Node harus dapat mengambil data yang mereka butuhkan tanpa bergantung pada sistem individual apa pun - baik itu repositori terpusat atau penerbit asli data. Jika beberapa pihak memiliki sepotong data, mereka harus berbagi beban pengirimannya ke siapa pun yang menginginkannya. Tidak ada yang perlu mempercayai sumber data individu, karena hash on-chain dapat membuktikan bahwa data belum diubah. Jika node berbahaya mengirimkan data yang salah untuk hash, saya dapat dengan mudah membuang data tersebut dan mencoba bertanya kepada orang lain.

Bagi mereka yang memiliki pengalaman dengan berbagi file peer-to-peer protokol seperti Napster, Gnutella atau BitTorrent, ini semua akan terdengar sangat familiar. Memang, banyak dari prinsip dasarnya yang sama, tetapi ada dua perbedaan utama. Pertama, dengan asumsi kami menggunakan blockchain kami dalam konteks perusahaan, sistem berjalan dalam grup peserta tertutup, bukan Internet secara keseluruhan. Kedua, blockchain menambahkan urutan terdesentralisasi, timestamping dan tulang punggung notaris, memungkinkan semua pengguna untuk mempertahankan pandangan yang terbukti konsisten dan tahan gangguan tentang apa yang sebenarnya terjadi, kapan dan oleh siapa.

Bagaimana pengembang aplikasi blockchain mencapai pengiriman konten off-chain yang terdesentralisasi ini? Salah satu pilihan yang umum adalah menggunakan platform berbagi file peer-to-peer yang ada, seperti nama yang lucu Sistem File Antar Planet (IPFS), dan gunakan bersama dengan blockchain. Setiap peserta menjalankan node blockchain dan node IPFS, dengan beberapa middleware yang berkoordinasi di antara keduanya. Saat menerbitkan data off-chain, middleware ini menyimpan data asli di IPFS, kemudian membuat transaksi blockchain yang berisi hash data tersebut. Untuk mengambil beberapa data off-chain, middleware mengekstrak hash dari blockchain, kemudian menggunakan hash ini untuk mengambil konten dari IPFS. Node IPFS lokal secara otomatis memverifikasi konten yang diambil terhadap hash untuk memastikannya tidak diubah.

Meskipun solusi ini memungkinkan, semuanya agak canggung dan tidak nyaman. Pertama, setiap peserta harus menginstal, memelihara, dan memperbarui tiga perangkat lunak terpisah (node blockchain, node IPFS, dan middleware), yang masing-masing menyimpan datanya di tempat terpisah. Kedua, akan ada dua jaringan peer-to-peer terpisah, masing-masing dengan konfigurasinya sendiri, port jaringan, sistem identitas dan perizinan (walaupun perlu dicatat bahwa IPFS belum mendukung jaringan tertutup). Terakhir, menggabungkan IPFS dan blockchain dengan erat akan membuat middleware semakin kompleks. Misalnya, jika kita ingin data off-chain yang direferensikan oleh beberapa transaksi blockchain langsung diambil (dengan percobaan ulang otomatis), middleware harus terus aktif dan berjalan, mempertahankan status kompleksnya sendiri. Bukankah lebih baik jika node blockchain melakukan semua ini untuk kita?

Data off-chain di MultiChain 2.0

Hari ini kami dengan senang hati merilis versi pratinjau ketiga (alfa 3) dari MultiChain 2.0, dengan solusi yang sepenuhnya terintegrasi dan mulus untuk data off-chain. Setiap bagian informasi yang dipublikasikan ke aliran dapat menjadi on-chain atau off-chain seperti yang diinginkan, dan MultiChain menangani yang lainnya.

Tidak juga, maksud kami segala sesuatu. Sebagai pengembang yang membangun MultiChain, Anda tidak perlu khawatir tentang hash, penyimpanan lokal, penemuan konten, pengiriman terdesentralisasi, atau verifikasi data. Inilah yang terjadi di balik layar:

Node MultiChain penerbitan menulis data baru di penyimpanan lokalnya, mengiris item besar menjadi beberapa bagian untuk memudahkan pencernaan dan pengiriman.
Transaksi untuk menerbitkan item aliran off-chain secara otomatis dibuat, yang berisi potongan hash dan ukuran dalam byte.
Transaksi ini ditandatangani dan disiarkan ke jaringan, menyebar antar node dan memasuki blockchain dengan cara biasa.
Ketika sebuah node yang berlangganan aliran melihat referensi ke beberapa data off-chain, ia menambahkan potongan hash untuk data tersebut ke antrian pengambilannya. (Saat berlangganan ke aliran lama, node juga mengantrekan item off-chain yang diterbitkan sebelumnya untuk diambil.)
Sebagai proses latar belakang, jika ada potongan dalam antrian pengambilan node, kueri dikirim ke jaringan untuk menemukan potongan tersebut, seperti yang diidentifikasi oleh hash mereka.
Kueri potongan ini disebarkan ke node lain di jaringan dengan cara peer-to-peer (terbatas pada dua lompatan untuk saat ini - lihat detail teknis di bawah).
Setiap node yang memiliki data untuk sepotong dapat merespons, dan respons ini diteruskan ke pelanggan kembali di sepanjang jalur yang sama dengan kueri.
Jika tidak ada node yang menjawab kueri potongan, potongan tersebut dikembalikan ke antrean untuk dicoba lagi nanti.
Jika tidak, pelanggan memilih sumber yang paling menjanjikan untuk suatu potongan (berdasarkan lompatan dan waktu respons), dan mengirimkannya permintaan untuk data potongan tersebut, lagi-lagi di sepanjang jalur peer-to-peer yang sama dengan respons sebelumnya.
Node sumber mengirimkan data yang diminta, menggunakan jalur yang sama lagi.
Pelanggan memverifikasi ukuran data dan hash terhadap permintaan asli.
Jika semuanya sudah diperiksa, pelanggan menulis data ke penyimpanan lokalnya, membuatnya segera tersedia untuk diambil melalui API aliran.
Jika konten yang diminta tidak sampai, atau tidak cocok dengan hash atau ukuran yang diinginkan, potongan dikembalikan ke antrian untuk pengambilan selanjutnya dari sumber yang berbeda.

Yang terpenting, semua ini terjadi dengan sangat cepat. Dalam jaringan dengan latensi rendah, potongan kecil data off-chain akan sampai ke pelanggan dalam sepersekian detik dari transaksi yang mereferensikan mereka. Dan untuk aplikasi beban tinggi, pengujian kami menunjukkan bahwa MultiChain 2.0 alpha 3 dapat mempertahankan kecepatan lebih dari 1000 item off-chain atau 25 MB data off-chain yang diambil per detik, pada server mid-range (Core i7) dengan Koneksi internet. Semuanya berfungsi dengan baik dengan item off-chain hingga ukuran 1 GB, jauh melampaui batas 64 MB untuk data on-chain. Tentu saja, kami berharap dapat meningkatkan angka-angka ini lebih jauh karena kami menghabiskan waktu untuk mengoptimalkan MultiChain 2.0 selama fase beta.

Saat menggunakan data off-chain daripada data on-chain dalam aliran, pengembang aplikasi MultiChain harus melakukan dua hal:

Saat memublikasikan data, teruskan tanda "offchain" ke API yang sesuai.
Saat menggunakan API kueri aliran, pertimbangkan kemungkinan bahwa beberapa data di luar rantai mungkin belum tersedia, seperti yang dilaporkan oleh tanda "tersedia". Meskipun situasi ini jarang terjadi dalam keadaan normal, penting bagi pengembang aplikasi untuk menanganinya dengan tepat.

Tentu saja, untuk mencegah setiap node mengambil setiap item off-chain, item harus dikelompokkan bersama ke dalam aliran dengan cara yang tepat, dengan setiap node berlangganan aliran yang diminati tersebut.

Item on-chain dan off-chain dapat digunakan dalam aliran yang sama, dan berbagai fungsi kueri dan ringkasan aliran terkait dengan kedua jenis data secara identik. Ini memungkinkan penerbit untuk membuat pilihan yang sesuai untuk setiap item dalam aliran, tanpa mempengaruhi aplikasi lainnya. Misalnya, aliran item JSON tentang aktivitas orang mungkin menggunakan data off-chain untuk informasi identifikasi pribadi, dan data on-chain untuk sisanya. Pelanggan dapat menggunakan penggabungan JSON MultiChain untuk menggabungkan kedua jenis informasi menjadi satu JSON untuk dibaca.

Jika Anda ingin mencoba item aliran off-chain, cukup ikuti aturan MultiChain Mulai tutorial, dan pastikan untuk tidak melewatkan bagian 5.

Jadi apa selanjutnya?

Dengan dukungan tanpa batas untuk data off-chain, MultiChain 2.0 akan menawarkan langkah besar ke depan untuk aplikasi blockchain yang berfokus pada cap waktu dan notaris data skala besar. Dalam jangka panjang, kami sudah memikirkan tentang banyak kemungkinan penyempurnaan fitur ini di masa mendatang untuk edisi Komunitas dan / atau Perusahaan MultiChain:

Menerapkan aliran Baca baca izin menggunakan kombinasi item off-chain, hash asin, kueri potongan bertanda tangan, dan pengiriman terenkripsi.
Mengizinkan data off-chain untuk secara eksplisit “dilupakan”, baik secara sukarela oleh node individu, atau oleh semua node sebagai respons terhadap pesan on-chain.
Langganan streaming selektif, di mana node hanya mengambil data untuk item off-chain dengan penerbit atau kunci tertentu.
Menggunakan pohon merkle untuk mengaktifkan satu hash on-chain untuk mewakili item off-chain dalam jumlah tak terbatas, memberikan lompatan besar lainnya dalam hal skalabilitas.
Mesin penyimpanan yang dapat dicolokkan, memungkinkan data off-chain disimpan dalam database atau sistem file eksternal daripada disk lokal.
Node belajar dari waktu ke waktu di mana setiap jenis data off-chain biasanya tersedia di jaringan, dan memfokuskan kueri potongannya dengan tepat.

Kami ingin sekali dengar tanggapan Anda pada daftar di atas serta item off-chain pada umumnya. Dengan MultiChain 2.0 yang secara resmi masih dalam versi alfa, ada banyak waktu untuk menyempurnakan fitur ini sebelum rilis finalnya.

Sementara itu, kami telah mulai mengerjakan "Smart Filters", fitur utama terakhir yang direncanakan untuk Komunitas MultiChain 2.0. Filter Cerdas adalah bagian kode yang disematkan di blockchain yang menerapkan aturan khusus untuk memvalidasi data atau transaksi. Filter Cerdas memiliki beberapa kesamaan dengan "kontrak pintar", dan dapat melakukan banyak hal yang sama, tetapi memiliki perbedaan utama dalam hal keselamatan dan kinerja. Kami berharap dapat memberi tahu Anda lebih banyak pada waktunya.

Silakan kirim komentar di LinkedIn.

Detail teknis

Meskipun item aliran off-chain di MultiChain 2.0 mudah digunakan, item tersebut berisi banyak keputusan desain dan fitur tambahan yang mungkin menarik. Daftar di bawah ini terutama akan relevan untuk pengembang yang membangun aplikasi blockchain, dan dapat dilewati oleh jenis yang lebih sedikit teknis:

Kebijakan per aliran. Saat aliran MultiChain dibuat, secara opsional dapat dibatasi untuk mengizinkan hanya data on-chain atau off-chain. Ada beberapa kemungkinan alasan untuk melakukan ini, daripada mengizinkan setiap penerbit untuk memutuskan sendiri. Misalnya, item on-chain menawarkan jaminan ketersediaan yang ketat, sedangkan item off-chain lama mungkin tidak dapat diambil kembali jika penerbit dan pelanggan lain meninggalkan jaringan. Di sisi lain, item on-chain tidak dapat "dilupakan" tanpa memodifikasi blockchain, sedangkan item off-chain lebih fleksibel. Ini bisa menjadi penting dalam hal aturan privasi data, seperti peraturan GDPR baru Eropa.
Metadata on-chain. Untuk item off-chain, transaksi on-chain masih berisi penerbit item, key (s), format (JSON, text or binary) dan total size. Semua ini hanya membutuhkan sedikit ruang, dan membantu pengembang aplikasi menentukan apakah tidak tersedianya item off-chain menjadi perhatian untuk kueri aliran tertentu.
Batas dua lompatan. Saat menyampaikan kueri potongan di seluruh jaringan peer-to-peer, ada trade-off antara jangkauan dan kinerja. Meskipun akan bagus jika setiap kueri disebarkan di setiap jalur, ini dapat menyumbat jaringan dengan "obrolan" yang tidak perlu. Jadi untuk saat ini kueri potongan dibatasi hingga dua lompatan, yang berarti bahwa node dapat mengambil data off-chain dari rekan rekannya. Dalam jaringan yang lebih kecil dengan kurang dari 1000 node yang cenderung mencirikan perusahaan blockchain, kami yakin ini akan berfungsi dengan baik, tetapi mudah bagi kami untuk menyesuaikan batasan ini (atau menawarkannya sebagai parameter) jika ternyata kami salah.
Penyimpanan lokal. Setiap node MultiChain menyimpan data off-chain dalam direktori "chunks" dari direktori blockchain regulernya, menggunakan format biner yang efisien dan indeks LevelDB. Subdirektori terpisah digunakan untuk item di setiap aliran langganan, serta yang diterbitkan oleh node itu sendiri. Dalam setiap subdirektori ini, potongan duplikat (dengan hash yang sama) hanya disimpan satu kali. Ketika sebuah node berhenti berlangganan dari aliran, ia dapat memilih apakah akan membersihkan data off-chain yang diambil untuk aliran itu atau tidak.
Cache biner. Saat memublikasikan potongan besar data biner, baik on-chain atau off-chain, mungkin tidak praktis bagi pengembang aplikasi untuk mengirim data tersebut ke API MultiChain dalam satu permintaan JSON-RPC. Jadi, MultiChain 2.0 mengimplementasikan cache biner, yang memungkinkan sebagian besar data dibangun melalui beberapa panggilan API, dan kemudian dipublikasikan dalam langkah terakhir yang singkat. Setiap item dalam cache biner disimpan sebagai file sederhana di subdirektori "cache" dari direktori blockchain, memungkinkan gigabyte data juga didorong langsung melalui sistem file.
Memantau API. MultiChain 2.0 alpha 3 menambahkan dua API baru untuk memantau pengambilan data off-chain secara asinkron. API pertama menjelaskan keadaan antrian saat ini, menunjukkan berapa banyak potongan (dan berapa banyak data) yang menunggu atau ditanyakan atau diambil. API kedua menyediakan statistik agregat untuk semua kueri dan permintaan chunk yang dikirim sejak node dimulai, termasuk jumlah berbagai jenis kegagalan.
Siram saat dipublikasikan. Saat menerbitkan item off-chain, MultiChain memastikan bahwa salinan lokalnya dari data sepenuhnya ditulis (atau "dibilas") ke drive disk fisik sebelum transaksi yang mereferensikan data itu disiarkan ke jaringan. Jika tidak, jika node tidak cukup beruntung sehingga kehilangan daya segera setelah menyiarkan transaksi, data off-chain dapat hilang secara permanen. Ini bukan masalah untuk MultiChain itu sendiri, karena penundaan antara upaya pengambilan potongan tumbuh secara otomatis dari waktu ke waktu. Tapi itu bisa menyebabkan masalah pada level aplikasi, di mana semua orang mengetahui keberadaan beberapa data tapi tidak ada yang bisa menemukannya.
Penerbitan kinerja. Dengan membuang data off-chain ke disk dengan cara ini, MultiChain dapat menyebabkan penurunan performa, karena disk fisik lambat. Misalnya, hard drive 7200 rpm mid-range hanya dapat melakukan sekitar 100 penulisan data acak per detik, membatasi laju di mana node individu dapat mempublikasikan item off-chain. Ada tiga solusi yang mungkin untuk masalah ini. Pertama dan paling sederhana, node dapat menggunakan hard disk solid state device (SSD) daripada hard drive biasa, yang mendukung 10,000 operasi tulis acak per detik. Kedua, beberapa item off-chain dapat dipublikasikan dalam satu transaksi menggunakan API "createrawsendfrom". Dalam kasus ini, MultiChain menulis semua data off-chain yang dirujuk oleh transaksi dalam operasi disk tunggal. Akhirnya, MultiChain dapat dikonfigurasi untuk tidak membuang data off-chain ke disk sebelum menyiarkan transaksi yang mereferensikannya. Gunakan opsi ini dengan hati-hati.
Integrasi mata uang asli. Untuk kasus penggunaan yang memerlukannya, MultiChain selalu menawarkan opsi untuk menggunakan mata uang asli di blockchain untuk mencegah spam transaksi dan / atau memberi insentif kepada validator blok ("penambang"). Dalam kasus ini, transaksi harus menawarkan kepada penambang biaya minimum yang sebanding dengan ukurannya dalam byte, agar dapat diteruskan dan dikonfirmasi di rantai. Mekanisme ini telah diperpanjang untuk memungkinkan spam off-chain dicegah, dengan mewajibkan biaya tambahan minimum per kilobyte data off-chain yang dirujuk dalam suatu transaksi.
Node arsip. Jika sebuah node ingin berlangganan ke setiap aliran, dan oleh karena itu mengambil dan menyimpan setiap item off-chain yang diterbitkan, node dapat dikonfigurasi untuk melakukannya menggunakan parameter runtime "langganan otomatis". Setiap node tersebut akan bertindak sebagai backup untuk seluruh jaringan, menjamin bahwa item off-chain tidak akan hilang atau tidak tersedia, tidak peduli node lain mana yang hilang. Dapat dibayangkan perusahaan pihak ketiga menawarkan ini sebagai layanan komersial.