Halo, aku kerja ing tim proyek DRD KP (pendaftaran data sing disebarake kanggo ngawasi siklus urip set roda). Ing kene aku pengin nuduhake pengalaman tim kita ing ngembangake blokir perusahaan kanggo proyek iki miturut kendala teknologi. Aku biasane bakal ngomong babagan Kain Hyperledger, nanging pendekatan sing diterangake ing kene bisa diekstrapolasi menyang blokir sing diidini. Tujuan utama riset kita yaiku nyiapake solusi pamblokiran perusahaan supaya produk pungkasan bisa digunakake lan ora angel dijaga.
Ora bakal ana panemuan, solusi sing ora dikarepake, lan ora ana perkembangan unik sing bakal disorot ing kene (amarga aku ora duwe). Aku mung pengin nuduhake pengalaman andhap asor, nuduhake yen "iku bisa" lan, mbok menawa, maca babagan pengalaman wong liya kanggo nggawe keputusan sing apik lan ora apik ing komentar.
Masalah: Blockchains durung ukuran
Dina iki, upaya akeh pangembang ngarahake supaya blockchain dadi teknologi sing trep, lan dudu bom wektu ing bungkus sing apik. Saluran negara, rollup optimistis, plasma lan sharding bisa uga umum. Sawetara dina. Utawa bisa uga TON bakal nundha peluncuran maneh sajrone nem wulan, lan Grup Plasma sabanjure bakal mandheg. Kita bisa pracaya ing roadmap sabanjuré lan maca kertas putih sarwa ing wayah wengi, nanging kene lan saiki kita kudu nindakake soko karo apa kita duwe. Rampung.
Tugas sing disetel kanggo tim kita ing proyek saiki katon umum kaya iki: ana akeh subjek, tekan sawetara ewu, sing ora pengin mbangun hubungan kanthi kepercayaan; Sampeyan kudu mbangun solusi ing DLT sing bakal bisa digunakake ing PC biasa tanpa syarat kinerja khusus lan menehi pengalaman pangguna ora luwih elek tinimbang sistem akuntansi terpusat. Teknologi ing mburi solusi kasebut kudu nyilikake kemungkinan manipulasi data sing ala - mulane blockchain ana ing kene.
Slogan saka whitepapers lan media janji manawa pangembangan sabanjure bakal ngidini kita nggawe jutaan transaksi per detik. Apa tenan?
Mainnet Ethereum saiki mlaku ing ~30 tps. Amarga mung iki, angel dianggep minangka pamblokiran kanthi cara apa wae sing cocog kanggo kabutuhan perusahaan. Antarane solusi sing diidini ana benchmark sing nuduhake 2000 tps () utawa 3000 tps (, ana sethitik kurang ing publikasi, nanging sampeyan kudu njupuk menyang akun sing pathokan iki digawa metu ing mesin konsensus lawas). Was , sing ora menehi asil paling awon, 20000 tps, nanging nganti saiki iki mung riset akademik, nunggu implementasine stabil. Ora mungkin perusahaan sing bisa njaga departemen pangembang blockchain bakal ngetrapake indikator kasebut. Nanging masalahe ora mung throughput, ana uga latency.
Latency
Wektu tundha saka wayahe transaksi diwiwiti nganti disetujoni pungkasan dening sistem gumantung ora mung ing kacepetan pesen kasebut ngliwati kabeh tahap validasi lan pesenan, nanging uga ing paramèter pambentukan blok. Sanajan pamblokiran kita ngidini kita nindakake kanthi kacepetan 1000000 tps, nanging mbutuhake 10 menit kanggo ngasilake blok 488 MB, apa bakal luwih gampang kanggo kita?
Ayo goleki kanthi luwih rinci babagan siklus urip transaksi ing Hyperledger Fabric kanggo mangerteni ing ngendi wektu ngginakaken lan kepriye hubungane kanggo mblokir paramèter generasi.
dijupuk saka kene:
(1) Klien nggawe transaksi, dikirim menyang endorsing ora pati cetho, sing terakhir simulasi transaksi (nerapake owah-owahan sing digawe dening chaincode kanggo negara saiki, nanging ora tundhuk ing ledger) lan nampa RWSet - jeneng tombol, versi lan nilai dijupuk saka koleksi ing CouchDB, (2) endorser ngirim maneh RWSet sing wis ditandatangani menyang klien, (3) klien mriksa manawa ana tandha tangan kabeh kanca sing dibutuhake (endorser), banjur ngirim transaksi menyang layanan pesenan. , utawa ngirim tanpa verifikasi (mriksa isih bakal njupuk Panggonan mengko), layanan pesenan mbentuk pemblokiran lan (4) ngirim bali menyang kabeh kanca, ora mung endorser; kanca-kanca mriksa manawa versi kunci ing set sing diwaca cocog karo versi ing basis data, manawa kabeh endorser duwe tanda tangan, lan pungkasane nindakake blok kasebut.
Nanging ora mung kuwi. Tembung "orderer mbentuk blok" ora mung ndhelikake pesenan transaksi, nanging uga 3 panjaluk jaringan urut-urutan saka pimpinan menyang para pengikut lan bali: pimpinan nambah pesen menyang log, dikirim menyang para pengikut, sing terakhir nambahake. menyang log, ngirim konfirmasi replikasi sing sukses menyang pimpinan, pimpinan nindakake pesen, ngirim konfirmasi komitmen menyang pandherekipun, pandherekipun nindakaken. Sing luwih cilik ukuran lan wektu pambentukan blok, luwih asring layanan pesenan kudu nggawe konsensus. Kain Hyperledger duwe rong paramèter kanggo pambentukan blok: BatchTimeout - wektu pambentukan blok lan BatchSize - ukuran blok (jumlah transaksi lan ukuran blok kasebut ing bita). Sanalika salah siji paramèter tekan watesan, pamblokiran anyar dirilis. Node urutan luwih akeh, luwih suwe. Mulane, sampeyan kudu nambah BatchTimeout lan BatchSize. Nanging amarga RWSets diversi, luwih gedhe blok sing digawe, luwih gedhe kemungkinan konflik MVCC. Kajaba iku, minangka BatchTimeout mundhak, UX catastrophically degrades. Skema ing ngisor iki kanggo ngrampungake masalah kasebut katon cukup lan jelas kanggo aku.
Kepiye supaya ora ngenteni finalisasi pamblokiran lan ora kelangan kemampuan kanggo nglacak status transaksi
Sing luwih dawa wektu pambentukan lan ukuran blok, luwih dhuwur throughput pamblokiran kasebut. Siji ora langsung ngetutake saka liyane, nanging kudu eling yen netepake konsensus ing RAFT mbutuhake telung panjaluk jaringan saka pimpinan menyang para pengikut lan mburi. Node urutan luwih akeh, luwih suwe. Sing luwih cilik ukuran lan wektu pambentukan blok, luwih akeh interaksi kasebut. Kepiye carane nambah wektu generasi lan ukuran blok tanpa nambah wektu respon sistem kanggo pangguna pungkasan?
Kaping pisanan, kita kudu ngrampungake konflik MVCC sing disebabake dening ukuran blok sing gedhe, sing bisa uga kalebu RWSets sing beda karo versi sing padha. Temenan, ing sisih klien (gandhengan karo jaringan pamblokiran, iki bisa uga dadi backend, lan maksudku) sampeyan kudu Penanganan konflik MVCC, sing bisa dadi layanan sing kapisah utawa dekorator biasa ing ndhuwur telpon sing miwiti transaksi kanthi logika coba maneh.
Coba maneh bisa ditindakake kanthi strategi eksponensial, nanging latensi bakal mudhun kanthi eksponensial. Dadi sampeyan kudu nggunakake salah siji nyoba maneh kanthi acak ing watesan cilik tartamtu, utawa tetep. Kanthi mripat ing bisa tabrakan ing pilihan pisanan.
Langkah sabanjure yaiku nggawe interaksi klien karo sistem ora sinkron supaya ora ngenteni 15, 30 utawa 10000000 detik, sing bakal disetel minangka BatchTimeout. Nanging ing wektu sing padha, perlu kanggo njaga kemampuan kanggo verifikasi yen owah-owahan sing diwiwiti dening transaksi kasebut / ora dicathet ing pamblokiran.
Database bisa digunakake kanggo nyimpen status transaksi. Opsi sing paling gampang yaiku CouchDB amarga gampang digunakake: database duwe UI metu saka kothak, API REST, lan sampeyan bisa kanthi gampang nyetel replikasi lan sharding. Sampeyan mung bisa nggawe koleksi kapisah ing conto CouchDB sing padha nggunakake Fabric kanggo nyimpen negara donya. Kita kudu nyimpen jinis dokumen kasebut.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Dokumen iki ditulis ing basis data sadurunge transaksi dikirim menyang kanca-kanca, ID entitas bali menyang pangguna (ID sing padha digunakake minangka kunci) yen iki operasi nggawe, banjur kolom Status, TxID lan Error dianyari minangka informasi sing cocog ditampa saka kanca-kanca.
Ing skema iki, pangguna ora ngenteni pemblokiran pungkasane dibentuk, nonton roda muter ing layar sajrone 10 detik, dheweke nampa respon cepet saka sistem lan terus kerja.
Kita milih BoltDB kanggo nyimpen status transaksi amarga kita kudu nyimpen memori lan ora pengin mbuwang wektu ing interaksi jaringan karo server database kapisah, utamané nalika interaksi iki dumadi nggunakake protokol teks biasa. Miturut cara, apa sampeyan nggunakake CouchDB kanggo ngleksanakake skema kasebut ing ndhuwur utawa mung kanggo nyimpen negara donya, ing kasus apa wae, iku ndadekake pangertèn kanggo ngoptimalake cara data disimpen ing CouchDB. Kanthi gawan, ing CouchDB, ukuran simpul b-wit iku 1279 bita, kang luwih cilik tinimbang ukuran sektor ing disk, kang tegese loro maca lan rebalancing wit bakal mbutuhake akses fisik liyane kanggo disk. Ukuran optimal cocog karo standar lan 4 kilobyte. Kanggo ngoptimalake kita kudu nyetel parameter btree_chunk_size padha karo 4096 ing file konfigurasi CouchDB. Kanggo BoltDB intervensi manual kuwi .
Backpressure: strategi buffer
Nanging bisa uga akeh pesen. Luwih saka sistem bisa nangani, nuduhake sumber daya karo rolas layanan liyane saliyane sing ditampilake ing diagram - lan kabeh iki kudu bisa flawlessly malah ing mesin kang mlaku Intellij Idea bakal arang banget tedious.
Masalah kapasitas beda sistem komunikasi, produser lan konsumen, ditanggulangi kanthi cara sing beda-beda. Ayo ndeleng apa sing bisa ditindakake.
Nempel: Kita bisa ngaku yen kita bisa ngolah paling akeh transaksi X ing detik T. Kabeh panjalukan ngluwihi watesan iki dibuwak. Iki cukup prasaja, nanging sampeyan bisa lali babagan UX.
Ngontrol: konsumen kudu duwe sawetara jinis antarmuka sing, gumantung saka beban, dheweke bisa ngontrol TPS produser. Ora ala, nanging ngetrapake kewajiban para pangembang klien sing nggawe beban kanggo ngetrapake antarmuka iki. Iki ora bisa ditampa kanggo kita, amarga pamblokiran ing mangsa ngarep bakal digabungake menyang pirang-pirang sistem sing wis suwe.
Panyebaran: Tinimbang nyoba kanggo nolak stream data input, kita bisa buffer stream iki lan proses ing kacepetan dibutuhake. Temenan iki minangka solusi sing paling apik yen kita pengin menehi pengalaman pangguna sing apik. Kita ngetrapake buffer nggunakake antrian ing RabbitMQ.
Rong tumindak anyar wis ditambahake menyang skema: (1) sawise panjalukan kanggo API teka, pesen karo paramèter sing perlu kanggo nelpon transaksi diselehake ing antrian, lan klien nampa pesen sing transaksi wis ditampa dening sistem, (2) backend maca data ing kacepetan kasebut ing config saka antrian; miwiti transaksi lan nganyari data ing nyimpen status.
Saiki sampeyan bisa nambah wektu tatanan lan mblokir kapasitas minangka akeh sing pengin, ndhelikake telat saka pangguna.
Piranti liyane
Ora ana sing diomongake ing kene babagan chaincode, amarga, minangka aturan, ora ana sing bisa dioptimalake. Chaincode kudu gampang lan aman - mung sing dibutuhake. Framework mbantu kita nulis chaincode kanthi gampang lan aman saka S7 Techlab lan analyzer statis .
Kajaba iku, tim kita ngembangake seperangkat utilitas supaya bisa nggarap Fabric kanthi gampang lan nyenengake: , sarana kanggo (nambah / mbusak organisasi, simpul RAFT), sarana kanggo . Yen sampeyan pengin nyumbang, sampeyan olèh.
kesimpulan
Pendekatan iki ngidini sampeyan ngganti Kain Hyperledger kanthi gampang karo Quorum, jaringan Ethereum pribadi liyane (PoA utawa malah PoW), kanthi signifikan nyuda throughput sing nyata, nanging ing wektu sing padha njaga UX normal (loro kanggo pangguna ing browser lan kanggo sistem terpadu). Nalika ngganti Fabric karo Ethereum ing skema, sampeyan mung kudu ngganti logika layanan nyoba maneh / dekorator saka ngolah konflik MVCC menyang atomic nonce increment lan resending. Buffering lan panyimpenan status digawe iku bisa kanggo decouple wektu respon saka wektu tatanan pamblokiran. Saiki sampeyan bisa nambah ewu simpul pesenan lan ora wedi yen pamblokiran dibentuk asring banget lan mbukak layanan pesenan.
Sejatine, mung kuwi sing dakkarepake. Aku bakal bungah yen iki mbantu wong ing karya.
Source: www.habr.com