Саламатсызбы, мен DRD KP долбоорунун командасында иштейм (дөңгөлөк топтомдорунун жашоо циклине мониторинг жүргүзүү үчүн бөлүштүрүлгөн маалыматтар реестри). Бул жерде мен технологиянын чектөөлөрүндө бул долбоор үчүн ишкана блокчейнди иштеп чыгуу боюнча биздин команданын тажрыйбасы менен бөлүшкүм келет. Мен көбүнчө Hyperledger Fabric жөнүндө сөз кылам, бирок бул жерде сүрөттөлгөн ыкманы каалаган уруксат берилген блокчейнге экстраполяциялоого болот. Биздин изилдөөбүздүн түпкү максаты - акыркы продукт колдонууга жагымдуу жана аны сактоо өтө кыйын эмес болушу үчүн ишкананын блокчейн чечимдерин даярдоо.
Бул жерде эч кандай ачылыштар, күтүлбөгөн чечимдер болбойт жана эч кандай уникалдуу өнүгүүлөр баса белгиленбейт (анткени менде жок). Мен жөн гана өзүмдүн жөнөкөй тажрыйбам менен бөлүшкүм келет, "мүмкүн болгон" экенин көрсөткүм келет жана, балким, комментарийлерде башка адамдардын жакшы жана анчалык жакшы эмес чечимдерди кабыл алуу тажрыйбасы жөнүндө окугум келет.
Көйгөй: Блокчейндер азырынча масштабдуу эмес
Бүгүнкү күндө көптөгөн иштеп чыгуучулардын күч-аракети блокчейнди кооз каптамадагы убакыт бомбасы эмес, чындап ыңгайлуу технологияга айлантууга багытталган. Мамлекеттик каналдар, оптимисттик топтомдор, плазма жана бөлүү, балким, кадимки көрүнүшкө айланат. Бир күнү. Же, балким, TON кайрадан ишке киргизүүнү алты айга кийинкиге калтырат жана кийинки Плазма тобу өз ишин токтотот. Биз кийинки жол картасына ишенип, түнү жаркыраган ак кагаздарды окуй алабыз, бирок бул жерде жана азыр бизде болгон нерсе менен бир нерсе кылышыбыз керек. Ишти бүтүр.
Учурдагы долбоордо биздин команданын алдына коюлган милдет жалпысынан мындай көрүнөт: мамилелерди ишенимге негиздегиси келбеген, бир нече миңге жеткен көптөгөн субъекттер бар; Бул DLT боюнча чечимди куруу зарыл, ал атайын аткаруу талаптары жок жөнөкөй компьютерлерде иштей турган жана борборлоштурулган эсепке алуу тутумдарынан кем эмес колдонуучу тажрыйбасын камсыз кылат. Чечимдин артында турган технология маалыматтарды зыяндуу манипуляциялоо мүмкүнчүлүгүн азайтышы керек - ошондуктан блокчейн бул жерде.
Whitepapers жана массалык маалымат каражаттарынын ураандары бизге кийинки өнүгүү секундасына миллиондогон транзакцияларды жасоого мүмкүндүк берет деп убада кылат. Бул чынында эмне?
Mainnet Ethereum учурда ~ 30 tps иштеп жатат. Ушундан улам, аны корпоративдик муктаждыктарга ылайыктуу түрдө блокчейн катары кабыл алуу кыйын. Уруксат берилген чечимдердин арасында 2000 tps көрсөткөн эталондор бар () же 3000 кашык (, басылмада бир аз азыраак бар, бирок сиз эталондук эски консенсус кыймылдаткычында жүргүзүлгөнүн эске алышыңыз керек). болгон , бул эң начар натыйжаларды берген жок, 20000 XNUMX tps, бирок азырынча бул жөн гана академиялык изилдөө, анын туруктуу ишке ашырылышын күтүп жатат. Блокчейнди иштеп чыгуучулардын бөлүмүн кармап турууга мүмкүнчүлүгү бар корпорация мындай көрсөткүчтөрдү көтөрө албайт. Бирок маселе өткөрүү жөндөмдүүлүгүндө гана эмес, кечигүү да бар.
кечигүү
Транзакция башталган учурдан тартып системанын акыркы жактыруусуна чейинки кечигүү билдирүү валидациялоонун жана заказ берүүнүн бардык этаптарынан өтүү ылдамдыгынан гана эмес, блоктун түзүлүшүнүн параметрлеринен да көз каранды. Биздин блокчейн 1000000 10 488 tps ылдамдыкта иштөөгө мүмкүндүк берсе да, бирок XNUMX МБ блокту түзүү үчүн XNUMX мүнөт талап кылынат, бул биз үчүн жеңилдейби?
Келгиле, Hyperledger Fabricдеги транзакциянын өмүр циклин кененирээк карап көрөлү, убакыт кайда сарпталат жана анын блоктордун генерациясынын параметрлерине кандай тиешеси бар.
бул жерден алынган:
(1) Кардар транзакцияны түзөт, аны индоссациялоочу кесиптештерине жөнөтөт, экинчиси транзакцияны имитациялайт (чынжыр код менен жасалган өзгөртүүлөрдү учурдагы абалга колдонот, бирок бухгалтердик китепке кирбейт) жана RWSet - негизги аталыштарды, версияларды жана баалуулуктарды алат CouchDB коллекциясынан алынган, (2) индоссанттар кардарга кол коюлган RWSetти кайра жөнөтөт, (3) кардар же бардык зарыл болгон теңтуштардын (индоссанттар) колунун бар-жоктугун текшерет, андан кийин транзакцияны буйрутма кызматына жөнөтөт. , же аны текшерүүсүз жөнөтөт (текшерүү кийинчерээк болот), заказ берүү кызматы блокту түзөт жана (4) индоссанттарга эле эмес, бардык теңтуштарга кайра жөнөтөт; теңтуштар окуу топтомундагы негизги версиялар маалымат базасындагы версияларга дал келгенин, бардык индоссанттардын кол тамгалары бар экендигин текшерип, акыры блокту жасашат.
Бирок бул баары эмес. "Заказ берүүчү блокту түзөт" деген сөздөр транзакциялардын тартибин гана эмес, ошондой эле лидерден жолдоочуларга жана артка 3 ырааттуу тармактык суроо-талаптарды жашырат: лидер журналга билдирүү кошот, аны жолдоочуларга жөнөтөт, акыркысы аны кошот. алардын журналына, лидерге ийгиликтүү репликациянын ырастоосун жөнөтөт, лидер билдирүүнү ишке ашырат, жолдоочуларга милдеттенме тастыктоосун жөнөтөт, жолдоочулар ишке ашырат. Блокту түзүүнүн өлчөмү жана убактысы канчалык аз болсо, заказ берүү кызматы ошончолук көп консенсус түзүүгө туура келет. Hyperledger Fabric блокторду түзүү үчүн эки параметрге ээ: BatchTimeout - блок түзүү убактысы жана BatchSize - блок өлчөмү (транзакциялардын саны жана блоктун өзүнүн байт менен өлчөмү). Параметрлердин бири чекке жеткенде жаңы блок чыгарылат. Буйрутма түйүндөрү канчалык көп болсо, ошончолук көп убакыт талап кылынат. Ошондуктан, BatchTimeout жана BatchSize көбөйтүү керек. Бирок RWSets версиялангандыктан, биз жасаган блок канчалык чоң болсо, MVCC чатактарынын ыктымалдыгы ошончолук жогору болот. Мындан тышкары, BatchTimeout көбөйгөн сайын, UX катастрофалык түрдө начарлайт. Бул проблемаларды чечүүнүн төмөнкү схемасы мен үчүн акылга сыярлык жана ачык-айкын көрүнөт.
Блоктун бүтүшүн күтүүдөн кантип качуу жана транзакциянын абалын көзөмөлдөө мүмкүнчүлүгүн жоготпоо керек
Түзүү убактысы жана блоктун көлөмү канчалык көп болсо, блокчейндин өткөрүү жөндөмдүүлүгү ошончолук жогору болот. Бири экинчисинен түздөн-түз ээрчибейт, бирок RAFTте консенсус түзүү үчүн лидерден жолдоочуларга жана артка үч тармактык суроо талап кылынарын эстен чыгарбоо керек. Буйрутма түйүндөрү канчалык көп болсо, ошончолук көп убакыт талап кылынат. Блоктун түзүлүшүнүн көлөмү жана убактысы канчалык аз болсо, ошончолук мындай өз ара аракеттенүүлөр болот. Акыркы колдонуучу үчүн системанын жооп берүү убактысын көбөйтпөстөн, муундун убактысын жана блоктун көлөмүн кантип көбөйтүү керек?
Биринчиден, биз кандайдыр бир жол менен MVCC конфликттерин чечишибиз керек, ал чоң блоктун өлчөмү менен шартталган, ал бир эле версиясы менен ар кандай RWSets камтышы мүмкүн. Албетте, кардар тарабында (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 ачкыч катары колдонулат), эгерде бул түзүү операциясы болсо, андан кийин Статус, TxID жана Ката талаалары тиешелүү маалыматтар курдаштардан алынган сайын жаңыртылып турат.
Бул схемада колдонуучу блоктун биротоло пайда болушун күтпөй, экранда 10 секунд бою айлануучу дөңгөлөктү көрүп, ал системадан дароо жооп алып, ишин улантат.
Биз транзакция статустарын сактоо үчүн BoltDBди тандадык, анткени эстутумду үнөмдөшүбүз керек жана өзүнчө маалымат базасы сервери менен тармактык өз ара аракеттенүү үчүн убакытты текке кетиргибиз келбейт, айрыкча бул өз ара аракеттенүү жөнөкөй текст протоколу аркылуу ишке ашканда. Айтмакчы, сиз CouchDBди жогоруда сүрөттөлгөн схеманы ишке ашыруу үчүн колдоносузбу же жөн гана дүйнөлүк абалды сактоо үчүн колдонсоңуз да, кандай болгон күндө да CouchDBде маалыматтардын сакталышын оптималдаштыруу мааниси бар. Демейки боюнча, CouchDBде b-дарак түйүндөрүнүн өлчөмү 1279 байт, бул дисктеги сектордун көлөмүнөн бир топ кичине, демек, даракты окуу да, тең салмактоо да дискке көбүрөөк физикалык мүмкүнчүлүктү талап кылат. Оптималдуу өлчөмү стандартка туура келет жана 4 килобайт. оптималдаштыруу үчүн биз параметрди орнотуу керек btree_chunk_size 4096га барабар CouchDB конфигурация файлында. BoltDB үчүн мындай кол менен кийлигишүү .
Арткы басым: буфердик стратегия
Бирок билдирүүлөр көп болушу мүмкүн. Диаграммада көрсөтүлгөндөн башка дагы ондогон кызматтар менен ресурстарды бөлүшүү тутумдун колунан келбейт жана мунун баары Intellij Idea иштеген машиналарда да кемчиликсиз иштеши керек.
Өндүрүүчүнүн жана керектөөчүнүн байланыш системаларынын ар кандай мүмкүнчүлүктөрүнүн маселеси ар кандай жолдор менен чечилет. Келгиле, эмне кыла аларыбызды карап көрөлү.
коюу: Биз T секунданын ичинде эң көп X транзакцияларды иштете алабыз деп айта алабыз. Бул чектен ашкан бардык өтүнүчтөр жокко чыгарылат. Бул абдан жөнөкөй, бирок андан кийин UX жөнүндө унутуп койсоңуз болот.
көзөмөлдөө: керектөөчүнүн кандайдыр бир интерфейси болушу керек, ал аркылуу жүктөмгө жараша ал өндүрүүчүнүн TPSти башкара алат. Жаман эмес, бирок бул интерфейсти ишке ашыруу үчүн жүктү түзүүчү кардардын иштеп чыгуучуларына милдеттенмелерди жүктөйт. Бул биз үчүн кабыл алынгыс, анткени blockchain келечекте көп сандагы көптөн бери иштеп келе жаткан системаларга интеграцияланат.
Топтолууда: Киргизилген маалымат агымына каршы турууга аракет кылуунун ордуна, биз бул агымды буферлеп, аны керектүү ылдамдыкта иштете алабыз. Албетте, биз жакшы колдонуучу тажрыйбасын камсыз кылуу үчүн келсе, бул мыкты чечим болуп саналат. Биз буферди RabbitMQ ичинде кезек менен ишке ашырдык.
Схемага эки жаңы иш-аракет кошулду: (1) API'ге суроо-талап келгенден кийин, транзакцияны чакыруу үчүн зарыл болгон параметрлери бар билдирүү кезекке коюлат жана кардар транзакцияны кабыл алганы жөнүндө билдирүү алат. система, (2) сервер конфигурацияда көрсөтүлгөн ылдамдыкта маалыматтарды кезектен окуйт; транзакцияны баштайт жана статус дүкөнүндөгү маалыматтарды жаңылайт.
Эми сиз колдонуучудан кечигүүлөрдү жашырып, калыптандыруу убактысын көбөйтө аласыз жана кубаттуулукту каалагандай блоктосоңуз болот.
Башка аспаптар
Бул жерде чынжыр код жөнүндө эч нерсе айтылган эмес, анткени, эреже катары, анда оптималдаштыруу үчүн эч нерсе жок. Chaincode мүмкүн болушунча жөнөкөй жана коопсуз болушу керек - бул андан талап кылынат. Алкак бизге чынжыр кодду жөнөкөй жана коопсуз жазууга жардам берет S7 Techlab жана статикалык анализатордон .
Мындан тышкары, биздин команда Fabric менен иштөөнү жөнөкөй жана жагымдуу кылуу үчүн утилиталардын топтомун иштеп чыгууда: , үчүн пайдалуу программа (уюмдарды, RAFT түйүндөрүн кошуу/алып салуу), утилита үчүн . Эгер салым кошууну кааласаңыз, сизди кабыл алыңыз.
жыйынтыктоо
Бул ыкма Hyperledger Fabric'ти Quorum, башка жеке Ethereum тармактары (PoA же ал тургай PoW) менен оңой алмаштырууга, иш жүзүндөгү өткөрүү жөндөмдүүлүгүн бир топ кыскартууга, бирок ошол эле учурда кадимки UXти (браузердеги колдонуучулар үчүн да, интеграцияланган системалар үчүн да) сактоого мүмкүндүк берет. Схемадагы Fabric'ти Ethereum менен алмаштырганда, сиз MVCC конфликттерин иштетүүдөн атомдук эмес өсүшкө жана кайра жөнөтүүгө чейин кайра аракет кылуу кызматынын/декоратордун логикасын өзгөртүүңүз керек. Буферлөө жана статусту сактоо блок түзүү убактысынан жооп убактысын ажыратууга мүмкүндүк берди. Эми сиз миңдеген буйрутма түйүндөрүн кошуп, блоктор өтө тез-тез түзүлүп калат деп коркпоңуз жана буйрутма кызматын жүктөй аласыз.
Негизинен мен бөлүшкүм келгени ушул эле. Бул кимдир бирөөнүн ишине жардам берсе, мен кубанычтамын.
Source: www.habr.com