Platform blockchain R-chain: arsitektur umum dan evolusi

Halo bagi mereka yang mengikuti perkembangan penggunaan platform terdesentralisasi dalam proses korporat dan antar-perusahaan. Publikasi kami tentang topik ini terhenti pada awal 2018. Tidak, Raiffeisenbank tidak berhenti bekerja ke arah ini: waktunya telah tiba untuk beralih dari kalkulasi metodologis dan pengenalan dengan kapabilitas masing-masing teknologi ke penerapan kasus bisnis tertentu dalam lingkungan industri atau sedekat mungkin dengannya. Artikel ini cukup banyak dan sekaligus informatif. Oleh karena itu, kami mengharapkan keterlibatan Anda dan memperingatkan tentang format tutorial.











Pada 2016-2017, kami menyelesaikan sejumlah proyek penelitian untuk membangun platform pembiayaan perdagangan yang terdesentralisasi. Menggunakan uji Ethereum (Rinkeby) sebagai platform buku besar terdistribusi yang mendasari dan Ethereum Swarm sebagai alat berbagi file terdesentralisasi. Selain masalah umum dalam membangun platform terdesentralisasi, kami menguji kemungkinan kontrak pintar, penggunaan oracle, dan kontrak pintar arbitrase. Beberapa dari hasil ini adalah





Berdasarkan proyek penelitian ini,





Hasil dari pekerjaan yang agak panjang ini, seperti yang dikatakan militer, "penerimaan pasokan" dari IT Raiffeisenbank dari platform R-Chain reguler yang terdesentralisasi. Sekarang ditawarkan sebagai elemen layanan pelanggan untuk grup perusahaan dengan berbagai ukuran.



Kami berbagi fitur utama dalam membangun platform ini, dan juga berbicara tentang evolusi penggunaan berbagai komponen "teknis" di dalamnya - platform blockchain dan sistem file terdistribusi.

Kandungan

• Fitur sistem perusahaan dan antar-perusahaan
• Arsitektur platform umum
  
  
  • Arsitektur komponen perangkat lunak
  • Proses bisnis satu atap
  • Manfaat menggunakan proses bisnis satu atap
  • Kerugian menggunakan proses bisnis generik
  • Pemantauan jaringan host
• Evolusi penggunaan berbagai komponen teknis
• Pengalaman dalam penelitian dan pengoperasian platform perusahaan dan pengembangan lebih lanjutnya

Fitur sistem perusahaan dan antar-perusahaan

Agar implementasi platform ke dalam operasi industri dapat berjalan dengan lancar dan tanpa ekses yang tidak terduga bagi pengembang, perlu dipahami bahwa platform yang diajukan kepada calon peserta harus memenuhi persyaratan sebagai berikut:

• Platform harus memiliki operator - badan hukum yang bertanggung jawab kepada peserta untuk menjalankan fungsinya. Opsi - setiap orang untuk dirinya sendiri, semuanya akan diputuskan oleh konsensus para peserta, dan seterusnya, tipikal untuk platform blockchain publik, tidak akan berfungsi di sini.
• , . , - - 15 — , .
• « » , . , , , « » , .
• , , . , — .
• «» . , - — , , . , , — , .

Banyak orang di daftar ini akan terkejut menemukan bahwa kata "transaksi per detik" dan peringkat kinerja lainnya tidak ada. Pengalaman kami menunjukkan bahwa produktivitas bukanlah kondisi terpenting untuk implementasi platform yang sukses. Performanya harus "cukup", dan ada banyak arsitektur aliran data yang dapat secara dramatis meningkatkan throughput platform yang mendasarinya - dari register data hingga aliran turbo lateral. Kemungkinan proyek Anda akan mati karena kurangnya perhatian pada poin-poin di atas secara hiperbolik lebih tinggi.

Arsitektur platform umum

Arsitektur komponen perangkat lunak

Aplikasi yang kami gunakan dalam proyek penelitian kami pada 2016-2017 ditulis atas dasar integrasi langsung antarmuka dialog dengan komponen "teknis" dari platform terdistribusi - geth dan swarm. Namun, setelah menganalisis kemungkinan dan konsekuensi dari pendekatan ini, kami sampai pada kesimpulan bahwa perlu untuk memperkenalkan lapisan lain antara backend bisnis dan komponen "teknis" - adaptor dari objek bisnis terpadu. Teknik ini termasuk dalam pola yang cukup standar untuk membangun arsitektur perangkat lunak, yang, bagaimanapun, tidak mengurangi keefektifannya. Akibatnya, arsitektur perangkat lunak dari node platform kami mulai terlihat seperti ini:







Dalam arsitektur ini, aplikasi bisnistidak bekerja secara langsung dengan abstraksi komponen DLT, tetapi dengan "proses bisnis universal" bersyarat tertentu (selanjutnya disebut sebagai proses) - ia menciptakan suatu proses, mengubah status proses. Pengurangan struktur data dari proses universal dan operasi di atasnya ke data dan operasi yang digunakan dalam klien DLT dilakukan oleh sekumpulan komponen yang ditetapkan sebagai "Cermin proses bisnis". Mirror juga melakukan transformasi kebalikan dari informasi yang diterima dari klien DLT, dan juga memfilter informasi dengan proses yang tidak terkait dengan peserta - pemilik node. Jadi, pada setiap node, database proses bisnis di mana node ini mengambil bagian disimpan dalam keadaan sinkron, dan dalam format yang paling nyaman untuk aplikasi bisnis . Aplikasi Bisnisberinteraksi dengan database ini - database proses bisnis, menerima informasi tentang keadaan proses dan mentransfer operasi untuk mengubah keadaan ini.

Proses bisnis satu atap

Secara alami, pertanyaan muncul tentang properti apa yang harus diberkahi dengan proses bisnis universal sehingga menyediakan, di satu sisi, penggunaan maksimum dari keuntungan platform blockchain, dan di sisi lain, fleksibilitas dan fungsionalitas maksimum untuk digunakan dalam Aplikasi Bisnis. Kondisi tambahannya adalah kemampuan untuk mengimplementasikan properti yang dipilih pada sebagian besar platform DLT umum, yang fungsinya sangat berbeda dalam beberapa aspek (Ethereum / Quorum / Masterchain, Hyperledger Fabric, Corda, EOS, Waves). Berdasarkan pengalaman proyek kami sendiri dan proyek orang lain, kami sampai pada kesimpulan sebagai berikut.



Proses bisnis universal harus memiliki atribut berikut:

• Parameter proses (jenis proses, status, atribut konteks dari Proses)
• Daftar peran peserta proses
• Daftar dokumen elektronik terkait proses
• Proses peta transisi

Pada saat yang sama, platform harus, pada level komponen blockchain, menyediakan kondisi berikut untuk penyebaran proses di jaringan:

• Kelengkapan dan integritas informasi
• Kerahasiaan dokumen elektronik di luar lingkaran peserta dalam proses
• Kontrol mengikuti peta transisi proses
• Menyimpan sejarah perubahan dalam status proses

Untuk mengimplementasikan kemampuan ini, kontrak pintar "kerangka kerja" telah dikembangkan dengan set properti dan metode yang sesuai.



Mari kita pikirkan beberapa atribut dan kondisi yang terdaftar - apa, bagaimana dan mengapa.



Parameter proses- terbuka bersyarat, karena dikirim langsung melalui kontrak pintar. Untuk beberapa platform blockchain, mereka pada dasarnya bersifat publik (Ethereum / Masterchain), untuk yang lain mereka dapat ditutup dengan cara standar untuk memastikan privasi data (Kuorum - kontrak pintar pribadi, Hyperledger Fabric - saluran dan data pribadi). Mungkin yang paling penting dari parameter "inti" dari proses dalam implementasi kami adalah "jenis proses", karena ini membawa tidak hanya semantik, tetapi juga beban fungsional - tergantung pada "jenis proses", adaptor DLT memilih template kontrak pintar yang proses ini akan dilakukan Perkenalkan dirimu. Mengapa ini dibutuhkan? Jelas, ada banyak jenis transaksi dan proses bisnis yang beragam yang memastikan implementasinya.Dalam sejumlah besar kasus, proses bisnis pada dasarnya hanya berbeda dalam peta transisi (dari sudut pandang platform) dan dapat diimplementasikan dengan satu kontrak pintar yang mendukung peta transisi sewenang-wenang (selengkapnya di bawah). Tetapi momen yang cukup unik dapat dikaitkan dengan proses bisnis tertentu:

• (, )
• (, )
• (, )

Mencoba memformalkan, "memformat", dan menjejalkan semua potensi keragaman ini ke dalam satu kerangka kontrak pintar benar-benar utopis. Pengembangan template unik untuk jenis proses bisnis tertentu adalah cara yang jauh lebih efisien, memberikan fleksibilitas tinggi dan kemampuan untuk "keras" mem-flash elemen proses yang diperlukan dan pemeriksaan kritis langsung ke "inti" komponen blockchain. Ini akan mengecualikan kemungkinan manipulasi oleh peserta individu. Selain itu, platform secara keseluruhan akan menggabungkan penyatuan antarmuka untuk interaksi aplikasi bisnis dengan proses dan modularitas tinggi implementasi fungsi spesifik mereka.



"Atribut kernel" dari proses kami juga menyertakan "status" dan "catatan": yang pertama adalah deskripsi singkat dari status proses ("Baru", "Dibatalkan", "Ditutup", "OnApproval"), yang kedua adalah string "panjang" dengan deskripsi yang lebih rinci untuk "status". Kami membatasi panjang catatan menjadi sekitar 1000 karakter (misalnya, "Dana tidak mencukupi di rekening"), karena dokumen elektronik yang dilampirkan pada proses dimaksudkan untuk mentransfer sejumlah besar informasi (terutama rahasia).



Proses peta transisi- menjelaskan apakah peserta dengan peran tertentu dapat mengubah status proses dan ke mana. Kontrol atas diterimanya transisi dilakukan oleh "inti" komponen blockchain dan tidak dapat dipalsukan oleh peserta yang "tidak berdaya". Selain itu, peta navigasi dapat, misalnya, digunakan oleh aplikasi bisnis untuk menentukan tindakan yang mungkin dilakukan oleh pemilik node dalam status proses saat ini untuk pengelolaan yang tepat dari komponen dialog.



Transfer data rahasia.Untuk mentransfer informasi rahasia, dokumen elektronik digunakan yang dilampirkan ke proses. Aplikasi bisnis mengunggah dokumen yang diperlukan ke penyimpanan file lokal "Mirrors" dan menunjukkannya dalam operasi untuk mengubah status proses. Sebelum mentransfer dari penyimpanan lokal ke DFS, dokumen dienkripsi dengan kunci publik dari node penerima - peserta dalam proses tersebut. Setelah penampung kripto yang dihasilkan ditransfer ke DFS, tautan ke sana dan hash dari dokumen asli ditransfer ke kontrak pintar proses. Setelah menerima informasi tentang perubahan status proses, detail file diekstrak ke dalam database proses bisnis, dan kemudian wadah kripto diekstrak dari DFS menggunakan tautan dan didekripsi dengan kunci node penerima. Pemeriksaan dilakukan untuk memastikan bahwa hash dokumen yang ditentukan dalam kontrak pintar proses cocok,dokumen tersebut ditempatkan di penyimpanan file lokal dan tersedia untuk aplikasi bisnis. Dengan demikian, aplikasi bisnis hanya berfungsi dengan versi "terbuka" dari dokumen - semua kekhawatiran tentang transfer amannya diambil alih oleh "Mirror".



Sejarah perubahan status proses adalah urutan "bingkai", yang masing-masing terkait dengan satu operasi perubahan status proses. Dalam penerapan kami, kami menyimpan data berikut untuk setiap "bingkai" riwayat:

• status
• catatan
• pengenal pemrakarsa transaksi perubahan negara

Riwayat perubahan dicatat di tingkat kontrak pintar dan memungkinkan tidak hanya untuk melacak urutan transisi untuk tujuan audit, tetapi juga memungkinkan aplikasi bisnis untuk memproses rantai peristiwa dengan benar, bahkan dalam hal kedatangan satu kali mereka (misalnya, pembekuan, gangguan dalam fungsi, dll.).



Memastikan signifikansi hukum- masalah yang sangat penting, yang kami catat di bagian "Fitur sistem korporat dan antar-perusahaan". Kami awalnya melanjutkan dari konsep bahwa signifikansi hukum tidak boleh diberikan melalui platform blockchain, tetapi melalui penggunaan PKI eksternal yang memiliki dukungan peraturan atau tingkat kepercayaan yang sesuai di antara peserta platform. Secara kasar, dokumen elektronik yang memberikan dasar hukum untuk tindakan Anda (dokumen pembayaran, kontrak, permintaan, dll.) Dan dilampirkan pada proses harus ditandatangani atas dasar PKI "halal" (di Rusia - GOST, di suatu tempat di luar negeri, misalnya, SSL atau PGP / GPG). Aplikasi lini bisnis akan memverifikasi tanda tangan "eksternal" dan mengambil tindakan yang sesuai. Atau tidak, tergantung hasilnya. Seseorang akan berkatabahwa ini bukan "evangelis" dan "kita perlu meyakinkan pengacara tentang signifikansi hukum dari transaksi blockchain." Kami melalui banyak langkah dalam perjalanan ini dan hasilnya selalu sama. Namun, dalam kasus RusiaSertifikasi Masterchain membuka peluang tertentu dalam hal ini - seperti yang mereka katakan, "Selamat berburu!"

Manfaat menggunakan proses bisnis satu atap

Apa yang diberikan pendekatan ini pada kita pada akhirnya?

• Memperluas lingkaran pengembang potensial aplikasi bisnis yang terdesentralisasi. «» - - , - «» , . . -, Corda, «» Ethereum, Quorum. , - «» - .
• «» . , , , , , - . , «» «» ( ), «- » . , « , ...», . «» -, «» . , «» -, . , - , . , , , , , , «» insufficient funds for gas * price + value gas required exceeds allowance or always failing transaction.
• «» -. - - , -. -, , 75-95% . , , « , » . , :
  
  
  
  >>> - DFS, , , «» -. Ethereum, «» . - (TON!), . , . … , , .
  
  
  
  >>> - . , Ethereum — , , , , , — .
• . . . , , , , , , . , , , , — .
• . , , « , ». , . — -. , - ( ) — - .

-

Di sini, mungkin, seperti yang dinyanyikan dalam lagu terkenal - "Di belakang mereka Anda dapat mendengar gumaman ..." - misalnya, bahwa kode rantai Hyperledger Fabric atau Corda, tidak seperti Solidity yang sedikit terlalu elegan, memungkinkan Anda untuk menerapkan logika proses bisnis yang hampir tak terhingga rumitnya, dan pendekatan ini merusak fungsionalitasnya. Ya, mereka benar sekali. Kepada yang bergumam, saya akan mengingatkan Anda tentang beberapa pesan terkenal dari bidang rekayasa perangkat lunak:

• Di mana menempatkan logika bisnis - dalam prosedur tersimpan database atau dalam kode aplikasi bisnis?
• Mana yang lebih baik - mainframe atau komputer khusus?
• Apakah Anda yakin garis dasar yang Anda pilih akan mempertahankan kompatibilitas atas pembaruan kehidupan di masa mendatang? Dan secara umum akankah bertahan 2 tahun ke depan?

Jawabannya cukup sederhana jika:

• Anda memiliki banyak uang, waktu, dan spesialis blockchain gratis
• Anda yakin bahwa basis blockchain yang Anda pilih tidak perlu diubah dari kata "tidak pernah"
• Anda benar-benar perlu "memeras" kemampuan platform hingga 101%

Nah, kalau begitu - kalkulator khusus ... dalam artian Hyperledger Fabric atau Corda dengan jahitan pada cheyncode dan "pahat di batu" lainnya. Jika tidak, pikirkan sendiri ...

Pemantauan jaringan host

Mungkin bagi beberapa orang ini akan menjadi wahyu, tetapi pemantauan yang terorganisir dengan baik adalah dasar untuk pengoperasian sistem perangkat lunak yang berhasil di suatu perusahaan. Dan konsep ini tidak hanya mencakup (dan bahkan tidak begitu banyak) pemantauan infrastruktur standar server, tetapi pemantauan fungsional komponen perangkat lunak. Platform terdistribusi Anda seharusnya tidak hanya berfungsi dengan benar, tetapi juga membuat kesalahan dengan benar, menyediakan layanan dukungan dengan jumlah informasi yang cukup yang memungkinkan Anda untuk dengan cepat mengidentifikasi, mengidentifikasi, dan memperbaiki kegagalan. Bahkan lebih baik jika sistem pemantauan memiliki kemampuan proaktif - ini memungkinkan Anda untuk mengidentifikasi potensi "buruk" dan memblokir kemungkinan konsekuensi sebelum "terjadi".



Jika pada setiap saat Anda tidak memahami apa status node jaringan Anda dan apa yang terjadi pada mereka, tetapi akan bekerja "sesuai dengan sinyal pengguna" - lebih baik segera mengosongkan ruang dalam antrian dan tidak meluangkan waktu pelanggan yang terhormat.



Berdasarkan hal di atas, sejak awal pengembangan platform kami, sistem pemantauan proaktif telah dibangun di dalamnya. Mari kita gambarkan prinsip operasinya:

• Dalam basis blockchain dari platform, kontrak pintar khusus dibuat yang bertanggung jawab untuk mengumpulkan dan mendistribusikan data pemantauan (untuk singkatnya, kami akan menyebut kontrak pintar ini sebagai SCM)
• , (), « », , . , - .
• - « », — .
• DFS- « », .
• , DFS .
• , , :
  
  >
  
  > «» -
  
  > «» DFS
  
  > - ( Ethereum- )
  
  > «»
  
  > «» — , «»
  
  > «»
  
  > «»
  
  > jejak audit dari aplikasi bisnis

Pada nilai atau kombinasi nilai tertentu untuk indikator pemantauan, Mirror secara otomatis menghentikan pemrosesan antrian operasinya, memblokir munculnya konsekuensi potensial yang tidak diinginkan, misalnya:

• Jika terjadi kelambatan kritis dalam label kontrol saluran blockchain, yang diartikan sebagai simpul putus dari jaringan blockchain atau gangguan total dari fungsinya
• Jika terjadi kelambatan kritis dari label kontrol saluran DFS, yang ditafsirkan sebagai simpul putus dari jaringan DFS atau gangguan lengkap dari fungsinya
• Dalam kasus kesalahan dalam antrian operasi, semua operasi berikutnya yang terkait dengan objek bisnis ini (proses bisnis universal) diblokir

Perhatian khusus diberikan pada penanganan kesalahan database yang digunakan oleh "Mirror". Database ini digunakan tidak hanya sebagai antarmuka dengan aplikasi bisnis, tetapi juga sebagai tumpukan status untuk mesin status antrian operasi "Mirror". Pengalaman telah menunjukkan bahwa dengan adanya kesalahan tertentu saat mengubah data dalam tabel database, operasi perulangan dapat terjadi dengan pengiriman ulang besar-besaran transaksi dan kesenangan lainnya. Suatu kali, karena kesalahan serupa, dalam dua hari kami "membuat" volume setengah tahunan rantai di Kuorum. Oleh karena itu, jika kesalahan semacam ini terdeteksi, "Mirror" sepenuhnya dimatikan dan menunggu respons manual dari layanan dukungan.



Central Monitoring Nodes mengambil informasi dari semua node jaringan (termasuk mereka sendiri) dari SCM dan menganalisanya, memungkinkan deteksi tepat waktu dari kondisi berbahaya atau berpotensi bahaya seperti, misalnya:

• - DFS-
• - DFS-
• -
• «»
• «»

Gambar di bawah ini menunjukkan contoh monitor sederhana untuk salah satu jaringan pengujian kami:







Lebih banyak skema pemantauan proaktif "tingkat atas" dikembangkan dan diterapkan, termasuk aplikasi bisnis, tetapi di sini kita sampai pada batas goyah kekayaan intelektual pelanggan tertentu.



Jangan menyembunyikan fakta bahwa di beberapa jaringan blockchain kami, memantau lalu lintas merupakan mayoritas dari total lalu lintas. Dalam hal ini, bahkan ada pemikiran untuk menggunakan jadwal mengambang untuk frekuensi "probing parcels" - lebih sering selama jam kerja, lebih jarang selama jam non-kerja. Tapi itu sepadan. Betulkah.



Secara umum, pantau apa pun yang dapat Anda pikirkan selama bandwidth jaringan terdesentralisasi Anda memungkinkan. Kalian akan memuji para Dewa Pemrograman lebih dari satu atau dua kali ya, dan penulis artikel ini tentunya :)



Karena sebagai salah satu tafsir hukum Murphy mengatakan: "Kesalahan biasanya terletak pada posisi yang tidak ada yang meragukannya."

Evolusi penggunaan berbagai komponen teknis

Setelah mempertimbangkan kondisi umum untuk penyebaran dan pengoperasian jaringan desentralisasi perusahaan, serta prinsip arsitektur yang kami gunakan untuk membangun platform R-Chain, sekarang kita beralih ke cerita tentang bagaimana dan mengapa komponen teknis individualnya berevolusi dalam proses penerapan proyek tertentu.



Yang pertama adalah proyek penerbitan jaminan internasional , di mana mitra kami adalah kolega dari Belarusia - Maret-Desember 2018.



Kami mulai dengan konfigurasi Ethereum - Ethereum Swarm - Crypto-Pro (DLT-DFS-cryptography), yang telah membuktikan dirinya dengan baik dalam proyek penelitian. Alih-alih menggunakan jaringan PoA pengujian publik Ethereum Rinkeby, jaringan pribadi PoA Ethereum dan jaringan pribadi Ethereum Swarm diangkat. Awalnya, tidak ada masalah teknis yang muncul, tetapi kami mengalami masalah "kriptografi" - salah satu peserta Belarusia dengan tegas menolak untuk menggunakan alat kriptografi yang kami tawarkan, dengan mengacu pada undang-undang setempat tentang pengelolaan dokumen elektronik. Pada saat itu, tidak mungkin menemukan solusi berkualitas tinggi "pada saat ini", tetapi ada pemahaman yang mantap tentang peran sulit dan penting dari kriptografi dalam keberhasilan proyek internasional.



Sudah dalam proses menjalankan transaksi kontrol pada infrastruktur jaringan nyata (setiap peserta menggunakan node pada sumber daya mereka), kegagalan dalam pekerjaan Ethereum Swarm diidentifikasi - kerugian file berada pada level 20%. Telah disarankan bahwa kerugian tersebut karena masalah di klien Swarm saat mengirim banyak file secara paralel. Secara umum, asumsi ini telah dikonfirmasi: secara eksperimental, kami berhasil menemukan jeda antara mengirim file individu ke Swarm dalam 5 detik. Selama transisi ke konfigurasi jaringan yang sepenuhnya bertempur, yang, karena kekhasan segmentasi jaringan yang digunakan dalam infrastruktur Raiffeisenbank, memerlukan pembuatan node Swarm transit, masalah kritis muncul - Ethereum Swarm memungkinkan hingga 30% file hilang saat bekerja melalui node transit.Arsitektur "berlapis" dan sistem pemantauan yang baik memungkinkan untuk berhasil melaksanakan masalah jaminan yang sebenarnya dalam mode "pemompaan bensin manual", tetapi nasib Ethereum Swarm ditutup. Harus dikatakan bahwa kemampuan Ethereum Swarm yang dinyatakan untuk bekerja dalam topologi tanpa koneksi pengirim-penerima langsung adalah salah satu alasan utama untuk memilihnya sebagai basis teknologi untuk DFS, dan ketidakmampuannya untuk bekerja dengan andal dalam mode ini menciptakan banyak masalah.dan ketidakmampuannya untuk bekerja dengan andal dalam mode ini menimbulkan banyak masalah.dan ketidakmampuannya untuk bekerja dengan andal dalam mode ini menimbulkan banyak masalah.



Perlu dicatat bahwa jaringan pribadi berdasarkan Ethereum dalam proyek ini senang dengan pemulihannya. Jadwal proyek mengasumsikan bahwa penutupan jaminan yang diterbitkan akan dilakukan 3 bulan setelah penerbitan, dan selama jeda ini, beberapa peserta menghentikan node mereka. Namun demikian, setelah memulai kembali jaringan tanpa tarian dengan rebana dalam 1 hari, integritasnya pulih, dan pengoperasian penutupan jaminan berjalan tanpa keluhan.



Proyek berikutnya adalah pembuatan jaringan intra-grup untuk Ascona Group of Companies - September 2018 - waktu saat ini.



Berdasarkan pengalaman proyek jaminan internasional, IPFS (InterPlanetary File System) dipilih sebagai basis teknologi untuk DFS. Ini berfungsi dengan baik untuk mengirim file secara paralel, dan tidak memerlukan penyesuaian mode khusus. Mungkin satu-satunya titik lemah dari IPFS adalah ketidakmungkinan (ditentukan!) Untuk bekerja dalam topologi "transit". Ketika membangun jaringan dengan jumlah peserta yang besar, penerapan masing-masing dari mereka dari akses "bintang penuh" dari masing-masing ke masing-masing, secara halus, merupakan masalah organisasi. Di sisi lain, semua peserta menerapkan akses antara mereka dan node "dukungan" operator. Oleh karena itu, untuk mengatur kelancaran distribusi file, mekanisme berikut diterapkan:

• Ketika file dilampirkan ke kontrak cerdas dari proses bisnis tertentu, acara DeliveryFile dibuat berisi tautan ke file tersebut.
• DeliveryFile IPFS. IPFS , , . .
• , , , «» ,

Dengan demikian, proyek Ascona dimulai dalam konfigurasi Ethereum - IPFS - Crypto-Pro.



Penggunaan Crypto-Pro untuk enkripsi file dan tanda tangan "eksternal" dari dokumen yang secara hukum signifikan memastikan kesederhanaan pengikatan hukum, serta tidak adanya klaim dari departemen Keamanan Informasi, yang pada gilirannya memiliki efek yang sangat positif pada waktu untuk memperoleh persetujuan yang diperlukan dari bank dan pihak perusahaan dari Ascona Group of Companies. Secara umum, proyek dikembangkan dalam urutan kerja dan, setelah melewati tahap percontohan, berada di garis finish untuk menuju produksi dan di sini ...



... dan di sini, dalam dua proyek sekaligus - bersyarat "asing", tetapi di mana kami berpartisipasi sebagai ahli, pada konfigurasi serupa kami menangkap mega-fork dari ribuan blok, dengan hilangnya transaksi dari sebagian jaringan. Analisis log dan interpretasi komunitas blockchain menghasilkan kesimpulan yang mengecewakan - penggunaan Ethereum PoA (dan dalam beberapa kasus bahkan PoW) dalam jaringan kompak dengan sejumlah kecil node (dan jaringan perusahaan tepat berada di sini) memiliki risiko tinggi untuk monster semacam itu. Selain itu, bug misterius mulai muncul secara berkala di jaringan pengujian kami, ketika sebuah node putus dari jaringan dan tidak lagi ingin melakukan sinkronisasi dengannya. Bahkan setelah menginstal ulang Ethereum dan menghapusnya sepenuhnya. Singkatnya, menjadi jelas bahwa jaringan prod membutuhkan alternatif dari basis blockchain. Dan cepat. Sangat cepat.



Solusinya ternyata Kuorum - praktis saudara Ethereum. Jumlah perbaikan di "Mirror" sangat minim, aplikasi bisnis tentu saja tidak membutuhkan perbaikan sama sekali.



Saat ini, transisi ke Kuorum hanya membawa keuntungan:

• Konsensus rakit yang digunakan menghilangkan garpu
• Tidak adanya blok kosong mengurangi ukuran rantai

Tidak adanya fork memungkinkan kita untuk melakukan tanpa jeda sambil menunggu penyelesaian transaksi bersyarat, yang sebelumnya diperlukan agar tidak menangani potensi rollback transaksi, dan kita memiliki hingga 6 siklus pembuatan blok. Ini, pertama, secara alami meningkatkan kinerja platform, dan kedua, menghilangkan masalah yang sangat sulit yang muncul jika fork telah melebihi jeda yang dihitung dan status objek bisnis "cermin" yang disentuhnya tidak lagi konsisten dengan status blockchainnya.



Satu-satunya, mungkin, fitur yang tidak menyenangkan dari Quorum adalah kemampuan untuk menghasilkan mega-block berukuran beberapa megabyte saat restart setelah jeda yang lama, yang hanya membuat adaptor DLT macet ketika mencoba membongkar isinya. Tapi, tegasnya, meja layanan tidak boleh tidur selama itu.



Sebagai hasil dari semua evolusi dramatis ini, kami sampai pada konfigurasi Quorum - IPFS - Crypto-PRO , yang sekarang kami gunakan di pasar domestik Rusia.



Mungkin seseorang akan mengajukan pertanyaan logis: "Nah, Anda belum pernah mendengar tentang Kuorum sebelumnya, atau apa?"... Kami telah mendengar tentang Quorum, Hyperledger Fabric, dan EOS. Penulis artikel ini bahkan menghadiri lokakarya Corda pertama dalam bahasa Rusia pada musim gugur 2017. Mungkin, khususnya untuk jawaban cerdas atas pertanyaan-pertanyaan semacam itu, Hegel menemukan Dialektika. Tim kecil yang memulai penelitian pada tahun 2016 memiliki pengalaman yang baik dalam mengembangkan aplikasi interaktif untuk Windows, dan Ethereum publik (uji coba dapat dimengerti) memiliki ambang masuk terendah dari platform blockchain. Dan karena kami tertarik untuk melakukan penelitian secara khusus pada topik blockchain, dan tidak bermain-main dengan buruh pelabuhan yang berbeda, yang tanpanya tidak realistis untuk meluncurkan Quorum atau Hyperledger Fabric "dewasa" (dan tidak pada semua platform Windows virtual dimungkinkan), maka pilihan sudah jelas. Seiring dengan hasil penelitian yang mulai menarik perhatian unit bisnis bank dan mitranya,menjadi mungkin untuk memperluas tim, mempercayakan sepatu bot kepada pembuat sepatu, dan kue ke kue, mendapatkan server Linux, dan seterusnya. Dan, tentu saja, tidak ada yang membuang solusi yang dikembangkan selama mereka mempertahankan potensi pengembangannya. Dialektika dan Evolusi.

Pengalaman dalam penelitian dan pengoperasian platform perusahaan dan pengembangan lebih lanjutnya

Penulis artikel ini mengambil bagian dalam sejumlah besar proyek blockchain yang dilakukan di Raiffeisenbank, di Asosiasi FinTech, dan di beberapa tempat lain - baik sebagai pengembang maupun sebagai pakar platform terdesentralisasi. Beberapa di antaranya adalah proyek penelitian murni, beberapa berakhir sebagai pilot, beberapa berkembang menjadi jaringan industri yang cukup besar dengan beberapa lusin node.



Apa kesimpulan utama yang bisa ditarik dari semua pengalaman ini?



1. Ada berbagai macam platform blockchain, yang sangat berbeda dalam kualitas "konsumen" mereka:

• "Ambang masuk" dan kemudahan penyebaran jaringan
• bandwidth
• fungsionalitas kontrak pintar
• opsi penutupan informasi
• waktu dan biaya pengembangan

Oleh karena itu, saya pikir tidak mungkin untuk mengatakan bahwa salah satu platform akan menjadi sangat dominan. Masing-masing memiliki lingkaran pengguna dan tugas potensial sendiri, di mana penggunaannya paling rasional dan hemat biaya. Ini berlaku untuk Ethereum, Quorum, Hyperledger Fabric, dan Corda. Di sini, seperti halnya bahasa pemrograman - hanya Vasya dan Petya, yang masing-masing tahu satu bahasa, akan berdebat sampai titik kebodohan tentang mana yang lebih baik - "plus" atau "katak". Dan Semyon Petrovich dan Albert Ivanovich, yang mengenal selusin dari mereka, akan berbicara dengan damai - saat "plus" lebih baik, dan saat - "katak".



2. Terlepas dari kenyataan bahwa beberapa platform DLT (misalnya, Hyperledger Fabric dan Corda) menyediakan kemampuan untuk mentransfer item data besar - pada kenyataannya, file, kemungkinan besar, basis blockchain dengan mekanisme kontrak cerdas dan fungsi transfer file akan tetap terpisah. Ini karena poin-poin berikut:

• , DLT-. . Hyperledger Fabric Corda 2M « », , IPFS 100M. - - pdf (, ), 50M — , .
• - , ( + ), , .
• , , S3. , , « », , DFS. .
• , , -, «» .

3. Saat ini, ada kekurangan kronis dari spesialis untuk layanan dukungan teknis dari platform desentralisasi. Lebih tepatnya, mereka tidak ada. Benar. Di sebagian besar proyek yang saya ketahui, sebagian besar pekerjaan dukungan teknis dilakukan oleh pengembang atau insinyur penelitian yang menciptakan platform ini, yang tentu saja tidak baik. Saya pikir hal ini disebabkan pemuda arahan dan secara bertahap pengembangan petunjuk teknis, templat respons, skema pemantauan dan materi metodologi lain yang diperlukan untuk mengatur pekerjaan yang efisien dari layanan dukungan sedang berlangsung. Salah satu masalah di sini adalah kurangnya kursus ikhtisar yang bagus dalam bahasa Rusia pada platform blockchain tertentu. Semuanya harus diteruskan dari tangan ke tangan. Namun spesialis dukungan di suatu perusahaan bukanlah pengembang, dan dia berfokus pada masalah lain: pemantauan,diagnosa kesalahan, memastikan ketersediaan dan pemulihan sistem setelah kecelakaan (apakah menurut Anda Anda tidak akan mengalami kecelakaan? Ya, tentu saja). Dan, sejujurnya, kemungkinan kematian proyek perusahaan karena dukungan yang buruk secara signifikan lebih tinggi daripada karena kualitas pembangunan yang buruk. Oleh karena itu, menarik spesialis berkualitas baik yang berpengalaman dalam mendukung dan mengoperasikan sistem perusahaan adalah faktor yang penting, jika bukan merupakan faktor terpenting dalam kenyataan bahwa proyek akan hidup dan berkembang untuk waktu yang lama, dan tidak akan layu segera setelah beberapa pendiri perusahaan meninggalkannya.Oleh karena itu, menarik spesialis berkualitas tinggi dengan pengalaman dalam mendukung dan mengoperasikan sistem perusahaan adalah faktor yang penting, jika bukan merupakan faktor terpenting dalam kenyataan bahwa proyek akan hidup dan berkembang untuk waktu yang lama, dan tidak akan layu segera setelah beberapa pendiri perusahaan meninggalkannya.Oleh karena itu, menarik spesialis berkualitas baik yang berpengalaman dalam mendukung dan mengoperasikan sistem perusahaan adalah faktor yang penting, jika bukan merupakan faktor terpenting dalam kenyataan bahwa proyek akan hidup dan berkembang untuk waktu yang lama, dan tidak akan layu segera setelah beberapa pendiri perusahaan meninggalkannya.



4. Salah satu bidang hukum yang paling suram adalah formalisasi hubungan antara operator dan peserta jaringan, yang diperparah oleh fakta bahwa operator, di satu sisi, bukan pemilik jaringan dan sumber dayanya, dan di sisi lain, berkewajiban untuk memastikan fungsinya, bahkan jika tindakan ini bertentangan dengan kepentingan masing-masing peserta. Keseimbangan antara hak dan kewajiban operator, "alat pengaruhnya" pada peserta jaringan, tanggung jawab keuangan operator - semua ini sekarang menjadi subjek sengketa yang sangat sulit. Pertanyaan paling sederhana:Bagaimana memastikan penggantian sinkron dari perangkat lunak penting oleh semua peserta jaringan, meskipun terlihat sederhana, menghasilkan diskusi yang sangat panas? Munculnya contoh formalisasi hukum posisi operator dan peserta jaringan berdasarkan pengalaman platform yang sudah masuk prod akan secara signifikan mempercepat pengenalan jaringan desentralisasi sebagai elemen penting dari hubungan korporat dan antar perusahaan.



Jika Anda telah mencapai akhir, ada juga bonus: beberapa pertanyaan tentang keadaan saat ini dan jalur pengembangan platform perusahaan terdesentralisasi tercermin dalam materi yang disiapkan oleh penulis artikel ini untuk salah satu sumber daya blockchain ( materi dirancang untuk berbagai pembaca ).