Halo, kuring damel di tim proyék DRD KP (pendaptaran data anu disebarkeun pikeun ngawaskeun siklus kahirupan set roda). Di dieu abdi hoyong bagikeun pangalaman tim kami dina ngembangkeun hiji blockchain perusahaan pikeun proyék ieu dina konstrain ditumpukeun ku téhnologi. Kanggo sabagéan ageung, kuring bakal ngobrol ngeunaan Hyperledger Fabric, tapi pendekatan anu dijelaskeun di dieu tiasa diekstrapolasi kana blokchain anu diidinan. Tujuan pamungkas tina panalungtikan urang nyaéta nyiapkeun solusi blockchain perusahaan ku cara anu produk ahirna pikaresepeun pikeun dianggo sareng henteu sesah dijaga.
Moal aya pamanggihan, solusi anu teu kaduga, sareng henteu aya kamajuan unik anu bakal katutupan di dieu (sabab kuring henteu gaduhna). Kuring ngan ukur hoyong bagikeun pangalaman hina kuring, nunjukkeun yén "éta mungkin" sareng, panginten, maca ngeunaan pangalaman batur dina ngadamel kaputusan anu saé sareng henteu saé dina koméntar.
Masalah: blockchains teu acan scalable
Kiwari, usaha seueur pamekar ditujukeun pikeun ngajantenkeun blockchain janten téknologi anu saé, sareng sanés bom waktos dina bungkus anu saé. Saluran kaayaan, rollup optimistis, plasma sareng sharding tiasa janten biasa. Sababaraha poé. Atawa meureun TON bakal deui nunda peluncuran salila genep bulan, sarta Plasma Grup salajengna bakal eureun aya. Urang tiasa percanten kana peta jalan anu sanés sareng maca kertas bodas anu saé wengi, tapi di dieu sareng ayeuna urang kedah ngalakukeun hiji hal sareng naon anu urang gaduh. Meunang sial.
Tugas ditugaskeun ka tim kami dina proyék ayeuna Sigana mah ieu dina istilah umum: aya loba subjék, ngahontal sababaraha sarébu, anu teu hayang ngawangun hubungan on trust; perlu ngawangun dina DLT solusi anu bakal dianggo dina PCS biasa tanpa syarat kinerja husus sarta nyadiakeun pangalaman pamaké teu leuwih goreng ti sagala sistem akuntansi terpusat. Téknologi balik solusi kedah ngaleutikan kamungkinan manipulasi data jahat - naha éta blockchain aya di dieu.
Slogan ti whitepapers jeung média janji urang yén ngembangkeun salajengna bakal ngidinan jutaan transaksi per detik. Naon éta sabenerna?
Mainnet Ethereum ayeuna ngajalankeun di ~ 30 tps. Kusabab ieu nyalira, hese nganggap éta salaku blockchain anu ku cara naon waé cocog pikeun kabutuhan perusahaan. Diantara solusi anu diidinan, tolok ukur anu nunjukkeun 2000 tps dipikanyaho () atanapi 3000 tps (, aya saeutik kirang dina publikasi, tapi tetep dina pikiran nu patokan ieu dilumangsungkeun dina mesin konsensus heubeul). Éta , nu masihan teu hasil awon, 20000 tps, tapi sajauh ieu ngan studi akademik ngantosan palaksanaan stabil maranéhanana. Teu mungkin yén hiji korporasi anu mampuh ngajaga departemén pamekar blockchain bakal nempatkeun indikator sapertos kitu. Tapi masalahna henteu ngan ukur dina throughput, aya ogé latency.
Latency
Reureuh ti momen hiji urus ngagagas nepi ka persetujuan final na ku sistem gumantung teu ukur dina laju pesen ngaliwatan sagala tahapan validasi jeung urutan, tapi ogé dina parameter formasi blok. Sanaos blockchain kami ngamungkinkeun urang komitmen dina 1000000 tps, tapi peryogi 10 menit pikeun ngabentuk blok 488MB, naha éta langkung gampang pikeun urang?
Hayu urang nyandak hiji tampilan ngadeukeutan dina siklus kahirupan hiji transaksi di Hyperledger Fabric ngartos naon butuh waktu jeung kumaha hubunganana pikeun meungpeuk parameter formasi.
dicokot ti dieu:
(1) Klien ngabentuk transaksi, ngirimkeunana ka peers anu ngesahkeun, anu terakhir simulate transaksi (nerapkeun parobihan anu dilakukeun ku chaincode kana kaayaan ayeuna, tapi henteu komitmen kana buku besar) sareng nampi RWSet - nami konci, versi sareng nilai dicokot tina koleksi di CouchDB, (2) endorsers ngirimkeun RWSet ditandatanganan deui ka klien, (3) klien boh mariksa tanda tangan sadaya peers perlu (endorsers), lajeng ngirimkeun urus ka mesen. jasa, atawa ngirimkeunana tanpa verifikasi (verifikasi masih bakal lumangsung engké), layanan pesenan ngabentuk blok jeung (4) ngirimkeun deui ka sadaya peers, teu ngan endorsers; peers pariksa yen versi konci dina set dibaca cocog versi dina database, tanda tangan sadaya endorsers, sarta tungtungna bunuh blok.
Tapi éta henteu sadayana. Tukangeun kecap "orderer ngabentuk blok" disumputkeun teu ukur mesen transaksi, tapi ogé 3 requests jaringan padeukeut ti pamimpin ka pengikut na deui: pamimpin nambahkeun pesen ka log, ngirim ka pengikut, dimungkinkeun tambahkeun ka. log maranéhanana, ngirim konfirmasi réplikasi suksés ka pamimpin, pamimpin commits pesen , ngirim commit konfirmasi ka pengikut, pengikut commit. Beuki leutik ukuran blok sareng waktosna, langkung sering jasa pesenan kedah ngadamel konsensus. Hyperledger Fabric gaduh dua parameter formasi blok: BatchTimeout - waktos formasi blok sareng BatchSize - ukuran blok (jumlah transaksi sareng ukuran blok sorangan dina bait). Pas salah sahiji parameter ngahontal wates, blok anyar dikaluarkeun. Beuki titik orderer, beuki lila ieu bakal butuh. Ku alatan éta, anjeun kudu ningkatkeun BatchTimeout na BatchSize. Tapi saprak RWSets anu versioned, nu badag urang nyieun blok, nu leuwih luhur kamungkinan bentrok MVCC. Sajaba ti éta, kalawan paningkatan dina BatchTimeout, UX degrades catastrophically. Sigana mah lumrah tur atra skéma handap pikeun ngarengsekeun masalah ieu.
Kumaha ngahindarkeun ngantosan finalisasi blok sareng henteu kaleungitan status transaksi
Beuki lila waktu formasi jeung ukuran blok, nu leuwih luhur throughput blockchain nu. Hiji henteu langsung nuturkeun ti anu sanés, tapi kedah émut yén netepkeun konsensus dina RAFT ngabutuhkeun tilu pamundut jaringan ti pamimpin ka pengikut sareng tukang. Langkung seueur titik pesenan, langkung lami waktosna. Beuki leutik ukuran sareng waktos formasi blok, langkung seueur interaksi sapertos kitu. Kumaha ningkatkeun waktos formasi sareng ukuran blok tanpa ningkatkeun waktos réspon sistem pikeun pangguna akhir?
Kahiji, anjeun kudu kumaha bae ngabéréskeun konflik MVCC disababkeun ku ukuran blok badag, nu bisa ngawengku RWSets béda jeung versi sarua. Jelas, dina sisi klien (dina hubungan sareng jaringan blockchain, ieu tiasa janten backend, sareng kuring hartosna éta) MVCC panangan konflik, anu tiasa janten jasa anu misah atanapi dekorator biasa dina telepon ngamimitian transaksi kalayan logika coba deui.
Coba deui bisa dilaksanakeun kalawan strategi eksponensial, tapi lajeng latency bakal degradasi éksponénsial ogé. Janten anjeun kedah nganggo uji coba deui sacara acak dina wates leutik anu tangtu, atanapi anu konstan. Kalawan hiji panon mun mungkin tabrakan dina varian munggaran.
Lengkah saterusna nyaéta nyieun interaksi klien jeung sistem asynchronous ku kituna teu ngadagoan 15, 30, atawa 10000000 detik, nu urang bakal nangtukeun salaku BatchTimeout. Tapi dina waktos anu sareng, perlu tetep kamampuhan pikeun mastikeun yén parobahan diprakarsai ku urus dirékam / teu kacatet dina blockchain nu.
Database tiasa dianggo pikeun nyimpen status transaksi. Pilihan panggampangna nyaéta CouchDB kusabab gampang dianggo: pangkalan data gaduh UI out of the box, API REST, sareng anjeun tiasa gampang nyetél réplikasi sareng sharding pikeun éta. Anjeun ngan ukur tiasa nyiptakeun koleksi anu misah dina conto CouchDB anu sami anu dianggo ku Fabric pikeun nyimpen kaayaan dunyana. Urang kedah nyimpen dokumén sapertos kieu.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Dokumén ieu ditulis kana pangkalan data sateuacan transaksi dikirim ka peers, ID éntitas dipulangkeun ka pangguna (ID anu sami dianggo salaku konci) upami ieu mangrupikeun operasi nyiptakeun, teras kolom Status, TxID sareng Kasalahan diropéa sakumaha informasi relevan narima ti peers.
Dina skéma ieu, pamaké teu ngadagoan blok ka tungtungna ngabentuk, ningali kabayang spinning dina layar pikeun 10 detik, anjeunna narima respon instan ti sistem jeung terus jalan.
Urang milih BoltDB pikeun nyimpen statuses urus sabab urang kudu ngahemat memori jeung teu hayang runtah waktu dina interaksi jaringan jeung server database stand-nyalira, utamana lamun interaksi ieu lumangsung ngagunakeun protokol téks polos. Ku jalan kitu, naha anjeun nganggo CouchDB pikeun nerapkeun skéma anu dijelaskeun di luhur atanapi ngan ukur pikeun nyimpen kaayaan dunya, dina sagala hal, éta masuk akal pikeun ngaoptimalkeun cara data disimpen dina CouchDB. Sacara standar, dina CouchDB, ukuran titik b-tangkal nyaéta 1279 bait, anu langkung alit tibatan ukuran séktor dina disk, anu hartosna yén maca sareng nyaimbangkeun deui tangkal bakal peryogi aksés disk anu langkung fisik. Ukuran optimal minuhan standar sareng 4 kilobyte. Pikeun optimasi, urang kedah nyetél parameter btree_chunk_size sarua jeung 4096 dina file konfigurasi CouchDB. Pikeun BoltDB campur manual sapertos .
tekanan deui: strategi panyangga
Tapi tiasa seueur pesen. Langkung ti anu tiasa diurus ku sistem, ngabagi sumber daya sareng belasan jasa sanés salian ti anu dipidangkeun dina diagram - sareng sadaya ieu kedah jalanna sacara sampurna sanajan dina mesin anu ngajalankeun Intellij Idea bakal pikasieuneun pisan.
Masalah throughput anu béda dina sistem komunikasi, produsén sareng konsumen, direngsekeun ku cara anu béda. Hayu urang tingali naon anu urang tiasa laksanakeun.
Henteu: urang bisa ngaku bisa ngolah paling X transaksi dina T detik. Sadaya pamundut anu ngaleuwihan wates ieu dileungitkeun. Ieu geulis basajan, tapi lajeng bisa poho ngeunaan UX.
Ngadalikeun: konsumen kudu boga sababaraha panganteur ngaliwatan nu, gumantung kana beban, anjeunna bisa ngadalikeun tps produser. Teu goréng, tapi imposes hiji kawajiban dina pamekar ti klien beban pikeun nerapkeun panganteur ieu. Pikeun urang, ieu teu bisa ditarima, saprak blockchain di mangsa nu bakal datang bakal terpadu kana sajumlah badag sistem lila-aya.
Panyebutan: tinimbang contriving nolak aliran data input, urang tiasa nyangga aliran ieu sarta ngolah eta dina speed diperlukeun. Jelas, ieu mangrupikeun solusi anu pangsaéna upami urang hoyong masihan pangalaman pangguna anu saé. Kami ngalaksanakeun panyangga nganggo antrian di RabbitMQ.
Dua lampah anyar geus ditambahkeun kana skéma: (1) sanggeus hiji pamundut API ditampi, pesen antrian kalawan parameter diperlukeun pikeun nelepon urus, sarta klien narima pesen yén urus geus ditarima ku sistem, ( 2) backend nu maca data dina speed dieusian dina config ti antrian; initiates transaksi sarta ngamutahirkeun data dina toko status.
Ayeuna anjeun tiasa ningkatkeun waktos ngawangun sareng meungpeuk kapasitas saloba anu anjeun pikahoyong, nyumputkeun telat ti pangguna.
Alat-alat sanésna
Henteu aya anu nyarios di dieu ngeunaan chaincode, sabab biasana henteu aya anu ngaoptimalkeun. Chaincode kedah saderhana sareng aman sabisa - éta sadayana anu diperyogikeun. Kerangka ngabantosan urang seueur nyerat kode ranté sacara sederhana sareng aman. ti S7 Techlab jeung analyzer statik .
Salaku tambahan, tim kami ngembangkeun sakumpulan utilitas pikeun ngajantenkeun damel sareng Fabric saderhana sareng pikaresepeun: , utiliti pikeun (nambahkeun / miceun organisasi, titik RAFT), utiliti pikeun . Upami anjeun hoyong nyumbang, wilujeng sumping.
kacindekan
Pendekatan ieu ngagampangkeun pikeun ngagentos Hyperledger Fabric sareng Quorum, jaringan Ethereum swasta sanés (PoA atanapi malah PoW), sacara signifikan ngirangan throughput nyata, tapi dina waktos anu sami ngajaga UX normal (duanana pikeun pangguna dina browser sareng tina sisi sistem terpadu. ). Nalika ngagentos Fabric sareng Ethereum dina skéma, ngan ukur logika jasa / dekorator anu kedah dirobih tina nanganan konflik MVCC kana paningkatan nonce atom sareng kiriman ulang. Buffering jeung neundeun status ngamungkinkeun pikeun decouple waktu respon ti waktu formasi blok. Ayeuna anjeun tiasa nambihan rébuan titik pesenan sareng henteu sieun yén blok sering kabentuk sareng ngamuat jasa pesenan.
Sacara umum, ieu sadayana anu kuring hoyong bagikeun. Kuring bakal bungah lamun eta mantuan batur dina karya maranéhanana.
sumber: www.habr.com