Сайн байна уу, би DRD KP төслийн багт ажилладаг (дугуйны багцын амьдралын мөчлөгийг хянах түгээсэн мэдээллийн бүртгэл). Технологийн хязгаарлалтын дор энэ төсөлд зориулж энтерпрайз блокчейн хөгжүүлсэн манай багийн туршлагыг энд хуваалцахыг хүсч байна. Ихэнх тохиолдолд би Hyperledger Fabric-ийн тухай ярих болно, гэхдээ энд тайлбарласан арга барилыг ямар ч зөвшөөрөгдсөн блокчэйнд экстраполяци хийх боломжтой. Бидний судалгааны эцсийн зорилго бол эцсийн бүтээгдэхүүнийг хэрэглэхэд таатай, хадгалахад тийм ч хэцүү биш байхаар аж ахуйн нэгжийн блокчейн шийдлүүдийг бэлтгэх явдал юм.
Энд ямар ч нээлт, гэнэтийн шийдлүүд, өвөрмөц бүтээн байгуулалтууд байхгүй (учир нь надад байхгүй). Би зүгээр л өөрийн даруухан туршлагаасаа хуваалцаж, "энэ нь боломжтой байсан" гэдгийг харуулахыг хүсч байна, магадгүй хэн нэгний сайн, тийм ч сайн биш шийдвэр гаргах туршлагын талаар сэтгэгдэл дээр уншина уу.
Асуудал: блокчейн нь өргөтгөх боломжгүй байна
Өнөөдөр олон хөгжүүлэгчдийн хүчин чармайлт нь блокчейныг үнэхээр тохиромжтой технологи болгоход чиглэгдэж байгаа бөгөөд энэ нь үзэсгэлэнтэй цаасан дээр тогтсон бөмбөг биш юм. Төрийн сувгууд, өөдрөг цуглуулга, плазм болон хуваалт нь ердийн зүйл болж магадгүй юм. Хэзээ нэгэн өдөр. Эсвэл TON дахин хөөргөхөө зургаан сараар хойшлуулж, дараагийн Плазма групп оршин тогтнохоо болино. Бид өөр замын зурагт итгэж, шөнийн цагаар гайхалтай цагаан цаас уншиж болно, гэхдээ энд, одоо бид байгаа зүйлээ хийх хэрэгтэй. Новшийг хий.
Одоогийн төсөлд манай багт өгсөн үүрэг даалгавар нь ерөнхийд нь иймэрхүү харагдаж байна: итгэлцэл дээр харилцаа холбоо тогтоохыг хүсдэггүй хэдэн мянгад хүрсэн олон субъектууд байдаг; DLT дээр тусгай гүйцэтгэлийн шаардлагагүйгээр энгийн компьютер дээр ажиллах шийдлийг бий болгох шаардлагатай бөгөөд хэрэглэгчийн туршлагыг ямар ч төвлөрсөн нягтлан бодох бүртгэлийн системээс дордуулахгүй. Шийдлийн цаадах технологи нь өгөгдөлд хор хөнөөл учруулах боломжийг багасгах ёстой - ийм учраас блокчэйн энд байна.
Цаашдын хөгжил нь секундэд сая сая гүйлгээ хийх боломжийг олгоно гэдгийг цагаан цаас болон хэвлэл мэдээллийн уриа лоозонгууд бидэнд амлаж байна. Энэ үнэхээр юу вэ?
Mainnet Ethereum одоогоор ~30 tps хурдтайгаар ажиллаж байна. Зөвхөн үүнээс болж үүнийг ямар нэгэн байдлаар корпорацийн хэрэгцээнд тохирсон блокчейн гэж ойлгоход хэцүү байдаг. Зөвшөөрөгдсөн шийдлүүдийн дунд 2000 tps-ийг харуулсан жишиг үзүүлэлтүүд мэдэгдэж байна () эсвэл 3000 халбага (, хэвлэлд арай бага байгаа боловч жишиг нь хуучин консенсус хөдөлгүүр дээр хийгдсэн гэдгийг санаарай). байсан , энэ нь хамгийн муу үр дүнг өгөөгүй, 20000 tps, гэхдээ одоогоор эдгээр нь тогтвортой хэрэгжилтийг хүлээж буй эрдэм шинжилгээний судалгаанууд юм. Блокчейн хөгжүүлэгчдийн хэлтсийг хадгалах чадвартай корпораци ийм үзүүлэлтийг тэсвэрлэх магадлал багатай юм. Гэхдээ асуудал нь зөвхөн дамжуулах чадварт төдийгүй хоцролттой холбоотой юм.
Лавлагаа
Гүйлгээг эхлүүлснээс хойш системээр эцсийн зөвшөөрөл авах хүртэлх хугацаа нь зөвхөн баталгаажуулалт, захиалгын бүх үе шатыг дамжих мессежийн хурдаас гадна блок үүсгэх параметрүүдээс хамаарна. Хэдийгээр манай блокчейн нь 1000000 tps хурдтай ажиллах боломжийг олгодог ч 10MB блок үүсгэхэд 488 минут зарцуулдаг ч энэ нь бидэнд илүү хялбар байх болов уу?
Hyperledger Fabric дахь гүйлгээний амьдралын мөчлөгийг нарийвчлан авч үзье, юунд цаг хугацаа хэрэгтэй, энэ нь блок үүсгэх параметрүүдтэй хэрхэн холбоотой болохыг ойлгох болно.
эндээс авсан:
(1) Үйлчлүүлэгч нь гүйлгээг бүрдүүлж, баталгаажуулсан нөхдөдөө илгээдэг, сүүлийнх нь гүйлгээг дуурайлган хийдэг (гинжин кодоор хийсэн өөрчлөлтийг одоогийн төлөвт ашиглах боловч дэвтэрт оруулахгүй) RWSet - түлхүүр нэр, хувилбарууд болон CouchDB дахь цуглуулгаас авсан утгууд, (2) дэмжигчид гарын үсэг зурсан RWSet-ийг үйлчлүүлэгч рүү буцааж илгээдэг, (3) үйлчлүүлэгч шаардлагатай бүх нөхдүүдийн гарын үсгийг шалгаж, дараа нь захиалгын үйлчилгээнд гүйлгээг илгээдэг. , эсвэл баталгаажуулахгүйгээр илгээсэн (баталгаажуулалт дараа нь хийгдэх болно), захиалгын үйлчилгээ нь блок үүсгэж, (4) зөвхөн баталгаажуулагч бус бүх үе тэнгийнхэндээ илгээдэг; Үе тэнгийнхэн нь уншсан багц дахь түлхүүрүүдийн хувилбарууд нь өгөгдлийн сан дахь хувилбарууд, бүх дэмжигчдийн гарын үсэгтэй таарч байгаа эсэхийг шалгаж, эцэст нь блоклоно.
Гэхдээ энэ нь бүгд биш юм. "Захиалагч блок үүсгэдэг" гэсэн үгсийн цаана зөвхөн гүйлгээний захиалга төдийгүй удирдагчаас дагалдагчдад болон буцаж ирэх 3 дараалсан сүлжээний хүсэлтүүд нуугддаг: удирдагч бүртгэлд мессеж нэмж, дагалдагчдад илгээдэг, сүүлийнх нь нэмдэг. Тэдний бүртгэл, удирдагч руу амжилттай хуулбарлагдсаны баталгааг илгээх, удирдагч мессеж илгээх, дагалдагчдад амлалтын баталгааг илгээх, дагалдагчид хийх. Блокны хэмжээ, цаг хугацаа бага байх тусам захиалгын үйлчилгээ нь зөвшилцлийг бий болгох шаардлагатай болдог. Hyperledger Fabric нь блок үүсгэх хоёр параметртэй: BatchTimeout - блок үүсгэх хугацаа ба BatchSize - блокийн хэмжээ (гүйлгээний тоо болон блокийн хэмжээ нь байтаар). Параметрүүдийн аль нэг нь хязгаарт хүрсэн даруйд шинэ блок гарна. Илүү олон захиалгын зангилаа, энэ нь удаан үргэлжлэх болно. Тиймээс та BatchTimeout болон BatchSize-ийг нэмэгдүүлэх хэрэгтэй. Гэхдээ RWSets нь хувилбартай тул бид блокыг том болгох тусам MVCC зөрчил үүсэх магадлал өндөр болно. Нэмж дурдахад, BatchTimeout нэмэгдэхийн хэрээр UX сүйрэлд хүргэдэг. Эдгээр асуудлыг шийдвэрлэх дараах схем нь үндэслэлтэй бөгөөд ойлгомжтой мэт санагдаж байна.
Блок дуусгахыг хүлээхээс хэрхэн зайлсхийх, гүйлгээний статусыг алдахгүй байх вэ
Үүсгэх хугацаа, блокийн хэмжээ урт байх тусам блокчейн дамжуулах чадвар өндөр болно. Нэг нь нөгөөгөөсөө шууд дагаж мөрддөггүй ч RAFT-д зөвшилцөлд хүрэхийн тулд удирдагчаас дагалдагчид болон буцаж ирэх гурван сүлжээний хүсэлтийг шаарддаг гэдгийг санах нь зүйтэй. Илүү олон захиалгын зангилаа, илүү их хугацаа шаардагдах болно. Блок үүсэх хэмжээ, цаг хугацаа бага байх тусам ийм харилцан үйлчлэл их байдаг. Эцсийн хэрэглэгчийн системийн хариу өгөх хугацааг нэмэгдүүлэхгүйгээр үүсэх хугацаа, блокийн хэмжээг хэрхэн нэмэгдүүлэх вэ?
Нэгдүгээрт, та ижил хувилбартай өөр өөр RWSet-г багтааж болох том хэмжээтэй блокоос үүдэлтэй MVCC зөрчлийг ямар нэгэн байдлаар шийдвэрлэх хэрэгтэй. Мэдээжийн хэрэг, үйлчлүүлэгчийн талд (blockchain сүлжээний хувьд энэ нь арын хэсэг байж магадгүй, би үүнийг хэлж байна) MVCC зөрчил зохицуулагч, энэ нь тусдаа үйлчилгээ эсвэл дахин оролдох логик бүхий гүйлгээг эхлүүлсэн дуудлагын дагуу ердийн засварлагч байж болно.
Дахин оролдлого нь экспоненциал стратегиар хэрэгжиж болох боловч дараа нь хоцролт нь мөн экспоненциалаар буурах болно. Тиймээс та тодорхой жижиг хязгаарт санамсаргүй байдлаар дахин оролдох эсвэл тогтмол нэгийг ашиглах хэрэгтэй. Эхний хувилбарт болзошгүй мөргөлдөөнийг анхаарч үзэх хэрэгтэй.
Дараагийн алхам бол үйлчлүүлэгчийн системтэй харилцах харилцааг 15, 30 эсвэл 10000000 секунд хүлээхгүйн тулд асинхрон болгох явдал бөгөөд бид үүнийг BatchTimeout гэж тохируулах болно. Гэхдээ үүнтэй зэрэгцэн гүйлгээний эхлүүлсэн өөрчлөлтүүд блокчэйнд бүртгэгдсэн / бүртгэгдээгүй эсэхийг шалгах чадварыг хадгалах шаардлагатай.
Гүйлгээний статусыг хадгалахын тулд мэдээллийн санг ашиглаж болно. Хамгийн хялбар сонголт бол CouchDB бөгөөд ашиглахад хялбар байдаг: өгөгдлийн сан нь UI, REST API-тай бөгөөд та үүнийг хуулбарлах, хуваахыг хялбархан тохируулах боломжтой. Та Fabric-ийн дэлхийн төлөвийг хадгалахдаа ашигладаг ижил CouchDB жишээн дээр тусдаа цуглуулга үүсгэж болно. Бид ийм төрлийн бичиг баримтыг хадгалах хэрэгтэй.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Энэ баримт бичгийг гүйлгээг үе тэнгийнхэн рүү илгээхээс өмнө мэдээллийн санд бичиж, хэрэв энэ нь үүсгэх үйлдэл бол тухайн байгууллагын ID-г хэрэглэгч рүү буцаана (ижил ID-г түлхүүр болгон ашигладаг), дараа нь Status, TxID, Error талбарууд гарч ирнэ. холбогдох мэдээллийг үе тэнгийнхнээсээ хүлээн авснаар шинэчлэгдсэн.
Энэ схемд хэрэглэгч блок эцэст нь үүсэхийг хүлээхгүй бөгөөд 10 секундын турш дэлгэцэн дээр эргэлдэж буй дугуйг харж, системээс шуурхай хариу хүлээн авч, үргэлжлүүлэн ажиллана.
Бид BoltDB-г гүйлгээний статусыг хадгалахын тулд сонгосон, учир нь бид санах ойг хэмнэх шаардлагатай бөгөөд бие даасан мэдээллийн сангийн сервертэй сүлжээний харилцан үйлчлэлд цаг үрэхийг хүсэхгүй байна, ялангуяа энэ харилцан үйлчлэл нь энгийн текст протоколыг ашиглан хийгддэг. Дашрамд хэлэхэд, та CouchDB-г дээр дурдсан схемийг хэрэгжүүлэхэд ашиглах эсвэл дэлхийн төлөвийг хадгалахад ашигладаг эсэхээс үл хамааран ямар ч тохиолдолд CouchDB-д өгөгдөл хадгалах аргыг оновчтой болгох нь зүйтэй юм. Анхдагч байдлаар CouchDB-д b модны зангилааны хэмжээ нь 1279 байт бөгөөд энэ нь диск дээрх секторын хэмжээнээс хамаагүй бага бөгөөд энэ нь модыг унших болон дахин тэнцвэржүүлэхэд илүү их физик дискэнд хандах шаардлагатай болно гэсэн үг юм. Хамгийн оновчтой хэмжээ нь стандартад нийцдэг бөгөөд 4 килобайт байна. Оновчлолын хувьд бид параметрийг тохируулах хэрэгтэй btree_chunk_size нь 4096-тай тэнцүү CouchDB тохиргооны файлд. BoltDB-ийн хувьд ийм гарын авлагын оролцоо .
Буфер даралт: буфер стратеги
Гэхдээ маш олон мессеж байж болно. Диаграммд үзүүлсэнээс гадна өөр хэдэн арван үйлчилгээтэй нөөцөө хуваалцаж, системийн зохицуулж чадахаас илүү бөгөөд энэ бүхэн Intellij Idea-г ажиллуулж байгаа машинууд дээр ч өө сэвгүй ажиллах ёстой.
Харилцаа холбооны систем, үйлдвэрлэгч, хэрэглэгч хоёрын харилцан адилгүй дамжуулах чадварын асуудлыг янз бүрийн аргаар шийддэг. Бид юу хийж чадахаа харцгаая.
Буулгах: бид T секундын дотор хамгийн ихдээ X гүйлгээг боловсруулах боломжтой гэж хэлж болно. Энэ хязгаараас хэтэрсэн бүх хүсэлтийг хасна. Энэ нь маш энгийн, гэхдээ дараа нь та UX-ийн талаар мартаж болно.
Хяналт: хэрэглэгч ачааллаас хамааран үйлдвэрлэгчийн tps-ийг хянах боломжтой интерфэйстэй байх ёстой. Муу биш, гэхдээ энэ нь ачааллын үйлчлүүлэгчийн хөгжүүлэгчдэд энэ интерфейсийг хэрэгжүүлэх үүрэг хүлээдэг. Бидний хувьд энэ нь хүлээн зөвшөөрөгдөхгүй, учир нь ирээдүйд блокчэйн нь олон тооны урт хугацааны системд нэгтгэгдэх болно.
Буферлэж байна: оролтын өгөгдлийн урсгалыг эсэргүүцэхийн оронд бид энэ урсгалыг буфер болгож, шаардлагатай хурдаар боловсруулж чадна. Мэдээжийн хэрэг, хэрэв бид хэрэглэгчийн сайн туршлагыг хангахыг хүсч байвал энэ нь хамгийн сайн шийдэл юм. Бид RabbitMQ-д дараалал ашиглан буферийг хэрэгжүүлсэн.
Уг схемд хоёр шинэ үйлдлийг нэмсэн: (1) API хүсэлтийг хүлээн авсны дараа гүйлгээг дуудахад шаардлагатай параметрүүд бүхий мессежийг дараалалд оруулж, үйлчлүүлэгч гүйлгээг систем хүлээн зөвшөөрсөн гэсэн мессежийг хүлээн авдаг, ( 2) арын хэсэг нь дарааллаас тохиргоонд заасан хурдаар өгөгдлийг уншдаг; гүйлгээг эхлүүлж, статусын хадгалалтын өгөгдлийг шинэчилдэг.
Одоо та бүтээн байгуулалтын цагийг нэмэгдүүлж, хүчин чадлыг хүссэн хэмжээгээр блоклож, саатлыг хэрэглэгчээс нууж болно.
Бусад хэрэгсэл
Энд гинжин кодын талаар юу ч хэлээгүй, учир нь үүнийг оновчтой болгох зүйл байдаггүй. Гинжин код нь аль болох энгийн бөгөөд аюулгүй байх ёстой - энэ бол шаардлагатай бүх зүйл юм. Энэхүү хүрээ нь бидэнд гинжин кодыг энгийн бөгөөд аюулгүй бичихэд маш их тусалдаг. S7 Techlab болон статик анализатороос .
Нэмж дурдахад, манай баг Fabric-тэй ажиллахыг хялбар бөгөөд тааламжтай болгохын тулд багц хэрэгслийг боловсруулж байна. , зориулалтын хэрэгсэл (байгууллага нэмэх/хасах, RAFT зангилаа), хэрэгсэл . Хэрэв та хувь нэмрээ оруулахыг хүсвэл тавтай морилно уу.
дүгнэлт
Энэхүү арга нь Hyperledger Fabric-ийг Кворум, бусад хувийн Ethereum сүлжээнүүд (PoA эсвэл бүр PoW)-аар солиход хялбар болгож, бодит дамжуулалтыг мэдэгдэхүйц бууруулж, харин UX-ийг хэвийн байлгахад тусалдаг (хөтөч болон нэгдсэн системүүдийн аль алиных нь хувьд). ). Схем дэх Fabric-ийг Ethereum-аар солих үед зөвхөн дахин оролдох үйлчилгээ/чимэглэгчийн логикийг л өөрчлөх шаардлагатай болно. Буфер болон статусын хадгалалт нь блок үүсгэх хугацаанаас хариу өгөх хугацааг салгах боломжтой болсон. Одоо та мянга мянган захиалгын зангилаа нэмж, блокууд хэтэрхий олон удаа үүсдэг гэж айж, захиалгын үйлчилгээг ачаалах боломжтой.
Ерөнхийдөө энэ бол миний хуваалцахыг хүссэн зүйл юм. Энэ нь хэн нэгэнд ажилд нь тусалдаг бол би баяртай байх болно.
Эх сурвалж: www.habr.com