చక్రాల కోసం పంపిణీ చేయబడిన రిజిస్ట్రీ: హైపర్‌లెడ్జర్ ఫ్యాబ్రిక్‌తో ఒక అనుభవం

హలో, నేను DRD KP ప్రాజెక్ట్ బృందంలో పని చేస్తున్నాను (చక్రాల సెట్ల జీవిత చక్రాన్ని పర్యవేక్షించడానికి పంపిణీ చేయబడిన డేటా రిజిస్ట్రీ). సాంకేతిక పరిమితులలో ఈ ప్రాజెక్ట్ కోసం ఎంటర్‌ప్రైజ్ బ్లాక్‌చెయిన్‌ను అభివృద్ధి చేయడంలో మా బృందం అనుభవాన్ని ఇక్కడ నేను పంచుకోవాలనుకుంటున్నాను. నేను ఎక్కువగా హైపర్‌లెడ్జర్ ఫ్యాబ్రిక్ గురించి మాట్లాడతాను, కానీ ఇక్కడ వివరించిన విధానం ఏదైనా అనుమతి ఉన్న బ్లాక్‌చెయిన్‌కి ఎక్స్‌ట్రాపోలేట్ చేయబడుతుంది. మా పరిశోధన యొక్క అంతిమ లక్ష్యం ఎంటర్‌ప్రైజ్ బ్లాక్‌చెయిన్ సొల్యూషన్‌లను సిద్ధం చేయడం, తద్వారా తుది ఉత్పత్తి ఉపయోగించడానికి ఆహ్లాదకరంగా ఉంటుంది మరియు నిర్వహించడం చాలా కష్టం కాదు.

ఇక్కడ ఎలాంటి ఆవిష్కరణలు, ఊహించని పరిష్కారాలు ఉండవు మరియు ప్రత్యేకమైన పరిణామాలు ఏవీ హైలైట్ చేయబడవు (ఎందుకంటే నా దగ్గర ఏదీ లేదు). నేను నా నిరాడంబరమైన అనుభవాన్ని పంచుకోవాలనుకుంటున్నాను, "ఇది సాధ్యమైంది" అని చూపించి, బహుశా, వ్యాఖ్యలలో మంచి మరియు అంత మంచి నిర్ణయాలు తీసుకోని ఇతర వ్యక్తుల అనుభవాల గురించి చదవాలనుకుంటున్నాను.

సమస్య: బ్లాక్‌చెయిన్‌లు ఇంకా స్కేల్ చేయలేదు

నేడు, చాలా మంది డెవలపర్‌ల ప్రయత్నాలు బ్లాక్‌చెయిన్‌ను నిజంగా అనుకూలమైన సాంకేతికతగా మార్చడం లక్ష్యంగా పెట్టుకున్నాయి మరియు అందమైన రేపర్‌లో టైమ్ బాంబ్ కాదు. రాష్ట్ర ఛానెల్‌లు, ఆశావాద రోల్అప్, ప్లాస్మా మరియు షార్డింగ్ బహుశా సాధారణం కావచ్చు. ఏదో ఒక రోజు. లేదా బహుశా TON మళ్లీ ఆరు నెలల పాటు ప్రయోగాన్ని వాయిదా వేస్తుంది మరియు తదుపరి ప్లాస్మా గ్రూప్ ఉనికిలో ఉండదు. మేము తదుపరి రోడ్‌మ్యాప్‌ను విశ్వసించగలము మరియు రాత్రిపూట అద్భుతమైన తెల్ల కాగితాలను చదవగలము, కానీ ఇక్కడ మరియు ఇప్పుడు మన వద్ద ఉన్న దానితో మనం ఏదైనా చేయాలి. పని పూర్తి చేయండి.

ప్రస్తుత ప్రాజెక్ట్‌లో మా బృందం కోసం సెట్ చేయబడిన టాస్క్ సాధారణంగా ఇలా కనిపిస్తుంది: అనేక సబ్జెక్టులు ఉన్నాయి, అనేక వేలకు చేరుకుంటాయి, వారు ట్రస్ట్‌పై సంబంధాలను పెంచుకోవడానికి ఇష్టపడరు; ప్రత్యేక పనితీరు అవసరాలు లేకుండా సాధారణ PCలలో పని చేసే DLTలో పరిష్కారాన్ని రూపొందించడం అవసరం మరియు ఏదైనా కేంద్రీకృత అకౌంటింగ్ సిస్టమ్‌ల కంటే అధ్వాన్నంగా వినియోగదారు అనుభవాన్ని అందిస్తుంది. పరిష్కారం వెనుక ఉన్న సాంకేతికత తప్పనిసరిగా డేటా యొక్క హానికరమైన మానిప్యులేషన్ యొక్క అవకాశాన్ని తగ్గించాలి - అందుకే బ్లాక్‌చెయిన్ ఇక్కడ ఉంది.

శ్వేతపత్రాలు మరియు మీడియా నుండి వచ్చే నినాదాలు, తదుపరి పరిణామం సెకనుకు మిలియన్ల కొద్దీ లావాదేవీలు చేయడానికి మాకు వీలు కల్పిస్తుందని వాగ్దానం చేస్తుంది. ఇది నిజంగా ఏమిటి?

Mainnet Ethereum ప్రస్తుతం ~30 tps వద్ద అమలవుతోంది. దీని కారణంగా మాత్రమే, కార్పొరేట్ అవసరాలకు తగిన విధంగా బ్లాక్‌చెయిన్‌గా భావించడం కష్టం. అనుమతించబడిన పరిష్కారాలలో 2000 టిపిఎస్‌లను చూపే బెంచ్‌మార్క్‌లు ఉన్నాయి (కోరం) లేదా 3000 టీపీఎస్ (హైపర్లెడ్జర్ ఫాబ్రిక్, ప్రచురణలో కొంచెం తక్కువగా ఉంది, కానీ పాత ఏకాభిప్రాయ ఇంజిన్‌లో బెంచ్‌మార్క్ నిర్వహించబడిందని మీరు పరిగణనలోకి తీసుకోవాలి). ఉంది రాడికల్ ఫ్యాబ్రిక్ ప్రాసెసింగ్‌లో ఒక ప్రయత్నం, ఇది చెత్త ఫలితాలను ఇవ్వలేదు, 20000 tps, కానీ ఇప్పటివరకు ఇది కేవలం విద్యాసంబంధ పరిశోధన, దాని స్థిరమైన అమలు కోసం వేచి ఉంది. బ్లాక్‌చెయిన్ డెవలపర్‌ల డిపార్ట్‌మెంట్‌ను నిర్వహించగలిగే స్థోమత ఉన్న కార్పొరేషన్ అటువంటి సూచికలను ఉంచడం అసంభవం. కానీ సమస్య నిర్గమాంశ మాత్రమే కాదు, జాప్యం కూడా ఉంది.

అంతర్గతాన్ని

సిస్టమ్ ద్వారా లావాదేవీ ప్రారంభించబడిన క్షణం నుండి దాని తుది ఆమోదం వరకు ఆలస్యం అనేది ధ్రువీకరణ మరియు ఆర్డర్ యొక్క అన్ని దశల గుండా సందేశం వెళ్ళే వేగంపై మాత్రమే కాకుండా, బ్లాక్ ఫార్మేషన్ పారామితులపై కూడా ఆధారపడి ఉంటుంది. మా బ్లాక్‌చెయిన్ 1000000 tps వేగంతో కట్టుబడి ఉండటానికి అనుమతించినప్పటికీ, 10 MB బ్లాక్‌ను రూపొందించడానికి 488 నిమిషాలు అవసరం అయినప్పటికీ, అది మనకు సులభంగా మారుతుందా?

హైపర్‌లెడ్జర్ ఫ్యాబ్రిక్‌లోని లావాదేవీ జీవితచక్రాన్ని నిశితంగా పరిశీలిద్దాం, సమయం ఎక్కడ వెచ్చిస్తారు మరియు బ్లాక్ జనరేషన్ పారామితులకు ఇది ఎలా సంబంధం కలిగి ఉంటుంది.

ఇక్కడ నుండి తీసుకోబడింది: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

(1) క్లయింట్ ఒక లావాదేవీని సృష్టిస్తుంది, దానిని ఆమోదించే సహచరులకు పంపుతుంది, రెండోది లావాదేవీని అనుకరిస్తుంది (ప్రస్తుత స్థితికి చైన్‌కోడ్ ద్వారా చేసిన మార్పులను వర్తింపజేయండి, కానీ లెడ్జర్‌కు కట్టుబడి ఉండకండి) మరియు RWSet - కీలక పేర్లు, సంస్కరణలు మరియు విలువలను అందుకుంటారు. CouchDBలోని సేకరణ నుండి తీసుకోబడింది, ( 2) ఆమోదదారులు సంతకం చేసిన RWSetని క్లయింట్‌కు తిరిగి పంపుతారు, (3) క్లయింట్ అవసరమైన అన్ని సహచరుల (ఎండార్సర్‌లు) సంతకాల ఉనికిని తనిఖీ చేసి, ఆపై లావాదేవీని ఆర్డరింగ్ సేవకు పంపుతారు , లేదా ధృవీకరణ లేకుండా పంపుతుంది (చెక్ ఇప్పటికీ తర్వాత జరుగుతుంది), ఆర్డరింగ్ సేవ ఒక బ్లాక్‌ను ఏర్పరుస్తుంది మరియు (4) కేవలం ఎండార్సర్‌లకు మాత్రమే కాకుండా అన్ని సహచరులకు తిరిగి పంపుతుంది; సహచరులు రీడ్ సెట్‌లోని కీలక సంస్కరణలు డేటాబేస్‌లోని సంస్కరణలతో సరిపోలుతున్నాయో లేదో తనిఖీ చేస్తారు, అన్ని ఎండార్సర్‌లు సంతకాలను కలిగి ఉంటారు మరియు చివరకు బ్లాక్‌ను చేస్తారు.

అయితే అదంతా కాదు. "ఆర్డరర్ బ్లాక్‌ను ఏర్పరుస్తుంది" అనే పదాలు లావాదేవీల క్రమాన్ని మాత్రమే కాకుండా, లీడర్ నుండి అనుచరులకు మరియు వెనుకకు 3 సీక్వెన్షియల్ నెట్‌వర్క్ అభ్యర్థనలను కూడా దాచిపెడతాయి: నాయకుడు లాగ్‌కు సందేశాన్ని జోడిస్తుంది, దానిని అనుచరులకు పంపుతుంది, తరువాతి దానిని జోడిస్తుంది వారి లాగ్‌కు, విజయవంతమైన ప్రతిరూపణ నిర్ధారణను నాయకుడికి పంపుతుంది, నాయకుడు సందేశాన్ని పంపుతాడు, అనుచరులకు నిబద్ధత నిర్ధారణను పంపుతాడు, అనుచరులు కట్టుబడి ఉంటారు. బ్లాక్ ఏర్పడే చిన్న పరిమాణం మరియు సమయం, తరచుగా ఆర్డరింగ్ సేవ ఏకాభిప్రాయాన్ని ఏర్పరచవలసి ఉంటుంది. హైపర్‌లెడ్జర్ ఫ్యాబ్రిక్ బ్లాక్ ఫార్మేషన్ కోసం రెండు పారామితులను కలిగి ఉంది: బ్యాచ్ టైమ్ అవుట్ - బ్లాక్ ఫార్మేషన్ టైమ్ మరియు బ్యాచ్‌సైజ్ - బ్లాక్ సైజు (లావాదేవీల సంఖ్య మరియు బ్లాక్ పరిమాణం బైట్‌లలో ఉంటుంది). పారామితులలో ఒకటి పరిమితిని చేరుకున్న వెంటనే, కొత్త బ్లాక్ విడుదల చేయబడుతుంది. ఎక్కువ ఆర్డర్ నోడ్‌లు, దీనికి ఎక్కువ సమయం పడుతుంది. అందువల్ల, మీరు బ్యాచ్‌టైమ్‌అవుట్ మరియు బ్యాచ్‌సైజ్‌ని పెంచాలి. కానీ RWSets సంస్కరణ చేయబడినందున, మనం చేసే బ్లాక్ ఎంత పెద్దదో, MVCC వైరుధ్యాల సంభావ్యత ఎక్కువగా ఉంటుంది. అదనంగా, BatchTimeout పెరిగేకొద్దీ, UX విపత్తుగా క్షీణిస్తుంది. ఈ సమస్యలను పరిష్కరించడానికి క్రింది పథకం నాకు సహేతుకమైనది మరియు స్పష్టంగా కనిపిస్తుంది.

బ్లాక్ ఫైనలైజేషన్ కోసం వేచి ఉండకుండా మరియు లావాదేవీ స్థితిని ట్రాక్ చేసే సామర్థ్యాన్ని కోల్పోకుండా ఎలా నివారించాలి

నిర్మాణం సమయం మరియు బ్లాక్ పరిమాణం ఎక్కువ, బ్లాక్‌చెయిన్ యొక్క నిర్గమాంశం ఎక్కువ. ఒకటి నేరుగా మరొకదానిని అనుసరించదు, కానీ RAFTలో ఏకాభిప్రాయాన్ని స్థాపించడానికి నాయకుడు నుండి అనుచరులకు మరియు వెనుకకు మూడు నెట్‌వర్క్ అభ్యర్థనలు అవసరమని గుర్తుంచుకోవాలి. ఎక్కువ ఆర్డర్ నోడ్‌లు, దీనికి ఎక్కువ సమయం పడుతుంది. బ్లాక్ ఫార్మేషన్ యొక్క పరిమాణం మరియు సమయం చిన్నది, అటువంటి పరస్పర చర్యలు ఎక్కువగా ఉంటాయి. తుది వినియోగదారు కోసం సిస్టమ్ ప్రతిస్పందన సమయాన్ని పెంచకుండా ఉత్పత్తి సమయాన్ని మరియు బ్లాక్ పరిమాణాన్ని ఎలా పెంచాలి?

ముందుగా, మేము పెద్ద బ్లాక్ పరిమాణం కారణంగా ఏర్పడే MVCC వైరుధ్యాలను ఎలాగైనా పరిష్కరించాలి, ఇందులో ఒకే వెర్షన్‌తో విభిన్న RWSets ఉండవచ్చు. సహజంగానే, క్లయింట్ వైపు (బ్లాక్‌చెయిన్ నెట్‌వర్క్‌కు సంబంధించి, ఇది బ్యాకెండ్ కావచ్చు మరియు నా ఉద్దేశ్యం) మీకు అవసరం MVCC సంఘర్షణ హ్యాండ్లర్, ఇది ప్రత్యేక సేవ లేదా కాల్ పైన ఉన్న సాధారణ డెకరేటర్ కావచ్చు, ఇది మళ్లీ ప్రయత్నించి లాజిక్‌తో లావాదేవీని ప్రారంభించవచ్చు.

ఘాతాంక వ్యూహంతో పునఃప్రయత్నాన్ని అమలు చేయవచ్చు, కానీ జాప్యం కూడా అంతే విపరీతంగా క్షీణిస్తుంది. కాబట్టి మీరు నిర్దిష్ట చిన్న పరిమితుల్లో యాదృచ్ఛికంగా మళ్లీ ప్రయత్నించాలి లేదా స్థిరమైనదాన్ని ఉపయోగించాలి. మొదటి ఎంపికలో సాధ్యమయ్యే ఘర్షణలపై దృష్టి పెట్టండి.

15, 30 లేదా 10000000 సెకన్ల వరకు వేచి ఉండకుండా ఉండేలా సిస్టమ్‌తో క్లయింట్ యొక్క పరస్పర చర్యను అసమకాలికంగా చేయడం తదుపరి దశ, దీనిని మేము బ్యాచ్‌టైమ్‌అవుట్‌గా సెట్ చేస్తాము. కానీ అదే సమయంలో, లావాదేవీ ప్రారంభించిన మార్పులు బ్లాక్‌చెయిన్‌లో నమోదు చేయబడలేదని ధృవీకరించే సామర్థ్యాన్ని నిర్వహించడం అవసరం.
లావాదేవీ స్థితిని నిల్వ చేయడానికి డేటాబేస్ ఉపయోగించవచ్చు. వాడుకలో సౌలభ్యం కారణంగా CouchDB అనేది సరళమైన ఎంపిక: డేటాబేస్ బాక్స్ వెలుపల UI, REST APIని కలిగి ఉంది మరియు మీరు దాని కోసం సులభంగా రెప్లికేషన్ మరియు షార్డింగ్‌ని సెటప్ చేయవచ్చు. మీరు దాని ప్రపంచ స్థితిని నిల్వ చేయడానికి ఫాబ్రిక్‌ను ఉపయోగించే అదే CouchDB ఉదాహరణలో ప్రత్యేక సేకరణను సృష్టించవచ్చు. మేము ఈ రకమైన పత్రాలను నిల్వ చేయాలి.

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

లావాదేవీని పీర్‌లకు పంపే ముందు ఈ పత్రం డేటాబేస్‌కు వ్రాయబడుతుంది, ఇది క్రియేషన్ ఆపరేషన్ అయితే ఎంటిటీ ID వినియోగదారుకు తిరిగి పంపబడుతుంది (అదే ID కీగా ఉపయోగించబడుతుంది), ఆపై స్థితి, TxID మరియు ఎర్రర్ ఫీల్డ్‌లు సహచరుల నుండి సంబంధిత సమాచారం అందుకున్నందున నవీకరించబడింది.

ఈ పథకంలో, బ్లాక్ చివరకు ఏర్పడే వరకు వినియోగదారు వేచి ఉండరు, స్క్రీన్‌పై స్పిన్నింగ్ వీల్‌ను 10 సెకన్ల పాటు చూస్తారు, అతను సిస్టమ్ నుండి తక్షణ ప్రతిస్పందనను అందుకుంటాడు మరియు పనిని కొనసాగిస్తాడు.

మేము మెమరీని సేవ్ చేయాల్సిన అవసరం ఉన్నందున మరియు ప్రత్యేక డేటాబేస్ సర్వర్‌తో నెట్‌వర్క్ ఇంటరాక్షన్‌లో సమయాన్ని వృథా చేయకూడదనుకుంటున్నందున లావాదేవీల స్థితిగతులను నిల్వ చేయడానికి మేము BoltDBని ఎంచుకున్నాము, ప్రత్యేకించి ఈ పరస్పర చర్య సాదా టెక్స్ట్ ప్రోటోకాల్‌ని ఉపయోగించి సంభవించినప్పుడు. మార్గం ద్వారా, మీరు పైన వివరించిన స్కీమ్‌ను అమలు చేయడానికి లేదా ప్రపంచ స్థితిని నిల్వ చేయడానికి CouchDBని ఉపయోగించినా, ఏదైనా సందర్భంలో CouchDBలో డేటా నిల్వ చేయబడే విధానాన్ని ఆప్టిమైజ్ చేయడం సమంజసం. డిఫాల్ట్‌గా, CouchDBలో, బి-ట్రీ నోడ్‌ల పరిమాణం 1279 బైట్‌లు, ఇది డిస్క్‌లోని సెక్టార్ పరిమాణం కంటే చాలా చిన్నది, అంటే చెట్టును చదవడం మరియు రీబ్యాలెన్స్ చేయడం రెండింటికీ డిస్క్‌కి మరింత భౌతిక యాక్సెస్ అవసరం అవుతుంది. సరైన పరిమాణం ప్రమాణానికి అనుగుణంగా ఉంటుంది అధునాతన ఆకృతి మరియు 4 కిలోబైట్లు. ఆప్టిమైజ్ చేయడానికి మనం పరామితిని సెట్ చేయాలి btree_chunk_size 4096కి సమానం CouchDB కాన్ఫిగరేషన్ ఫైల్‌లో. BoltDB అటువంటి మాన్యువల్ జోక్యం కోసం అవసరం లేదు.

బ్యాక్‌ప్రెషర్: బఫర్ వ్యూహం

కానీ చాలా సందేశాలు ఉండవచ్చు. సిస్టమ్ నిర్వహించగలిగే దానికంటే ఎక్కువ, రేఖాచిత్రంలో చూపిన వాటితో పాటు డజను ఇతర సేవలతో వనరులను పంచుకోవడం - మరియు ఇంటెల్లిజ్ ఐడియాను అమలు చేయడం చాలా శ్రమతో కూడుకున్న మెషీన్‌లలో కూడా ఇవన్నీ దోషపూరితంగా పని చేస్తాయి.

కమ్యూనికేట్ సిస్టమ్స్, నిర్మాత మరియు వినియోగదారు యొక్క విభిన్న సామర్థ్యం యొక్క సమస్య వివిధ మార్గాల్లో పరిష్కరించబడుతుంది. మనం ఏమి చేయగలమో చూద్దాం.

జారవిడిచిన: మేము T సెకన్లలో గరిష్టంగా X లావాదేవీలను ప్రాసెస్ చేయగలమని క్లెయిమ్ చేయవచ్చు. ఈ పరిమితిని మించిన అన్ని అభ్యర్థనలు విస్మరించబడతాయి. ఇది చాలా సులభం, కానీ మీరు UX గురించి మరచిపోవచ్చు.

కంట్రోలింగ్: వినియోగదారుడు తప్పనిసరిగా ఒక రకమైన ఇంటర్‌ఫేస్‌ను కలిగి ఉండాలి, దీని ద్వారా లోడ్‌పై ఆధారపడి, అతను నిర్మాత యొక్క TPSని నియంత్రించవచ్చు. చెడ్డది కాదు, కానీ ఈ ఇంటర్‌ఫేస్‌ను అమలు చేయడానికి లోడ్‌ను సృష్టించే క్లయింట్ యొక్క డెవలపర్‌లపై ఇది బాధ్యతలను విధిస్తుంది. ఇది మాకు ఆమోదయోగ్యం కాదు, ఎందుకంటే భవిష్యత్తులో బ్లాక్‌చెయిన్ పెద్ద సంఖ్యలో దీర్ఘకాలంగా ఉన్న సిస్టమ్‌లలో విలీనం చేయబడుతుంది.

బఫరింగ్: ఇన్‌పుట్ డేటా స్ట్రీమ్‌ను నిరోధించడానికి ప్రయత్నించే బదులు, మేము ఈ స్ట్రీమ్‌ను బఫర్ చేయవచ్చు మరియు అవసరమైన వేగంతో ప్రాసెస్ చేయవచ్చు. మేము మంచి వినియోగదారు అనుభవాన్ని అందించాలనుకుంటే సహజంగానే ఇది ఉత్తమ పరిష్కారం. మేము RabbitMQలో క్యూని ఉపయోగించి బఫర్‌ని అమలు చేసాము.

స్కీమ్‌కు రెండు కొత్త చర్యలు జోడించబడ్డాయి: (1) APIకి అభ్యర్థన వచ్చిన తర్వాత, లావాదేవీకి కాల్ చేయడానికి అవసరమైన పారామితులతో కూడిన సందేశం క్యూలో ఉంచబడుతుంది మరియు క్లయింట్ లావాదేవీని ఆమోదించినట్లు సందేశాన్ని అందుకుంటారు సిస్టమ్, (2) బ్యాకెండ్ క్యూ నుండి కాన్ఫిగరేషన్‌లో పేర్కొన్న వేగంతో డేటాను రీడ్ చేస్తుంది; స్థితి స్టోర్‌లో లావాదేవీని ప్రారంభిస్తుంది మరియు డేటాను అప్‌డేట్ చేస్తుంది.
ఇప్పుడు మీరు ఫార్మేషన్ సమయాన్ని పెంచుకోవచ్చు మరియు మీకు కావలసినంత బ్లాక్ కెపాసిటీని పెంచుకోవచ్చు, యూజర్ నుండి జాప్యాన్ని దాచవచ్చు.

ఇతర సాధనాలు

చైన్‌కోడ్ గురించి ఇక్కడ ఏమీ చెప్పబడలేదు, ఎందుకంటే, ఒక నియమం వలె, దానిలో ఆప్టిమైజ్ చేయడానికి ఏమీ లేదు. చైన్‌కోడ్ వీలైనంత సరళంగా మరియు సురక్షితంగా ఉండాలి - దానికి కావలసినది అంతే. చైన్‌కోడ్‌ను సరళంగా మరియు సురక్షితంగా వ్రాయడానికి ఫ్రేమ్‌వర్క్ మాకు సహాయపడుతుంది CCKit S7 Techlab మరియు స్టాటిక్ ఎనలైజర్ నుండి పునరుద్ధరించు^CC.

అదనంగా, మా బృందం ఫ్యాబ్రిక్‌తో పని చేయడం సులభం మరియు ఆనందించేలా చేయడానికి యుటిలిటీల సమితిని అభివృద్ధి చేస్తోంది: బ్లాక్‌చెయిన్ ఎక్స్‌ప్లోరర్, కోసం ఒక ప్రయోజనం автоматического изменения конфигурации сети (సంస్థలను జోడించడం/తొలగించడం, RAFT నోడ్‌లు), దీని కోసం యుటిలిటీ సర్టిఫికెట్ల రద్దు మరియు గుర్తింపు తొలగింపు. మీరు సహకరించాలనుకుంటే, మీకు స్వాగతం.

తీర్మానం

ఈ విధానం హైపర్‌లెడ్జర్ ఫ్యాబ్రిక్‌ను కోరమ్, ఇతర ప్రైవేట్ ఎథెరియం నెట్‌వర్క్‌లు (PoA లేదా PoW)తో సులభంగా భర్తీ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది, వాస్తవ నిర్గమాంశాన్ని గణనీయంగా తగ్గిస్తుంది, అయితే అదే సమయంలో సాధారణ UX (బ్రౌజర్‌లోని వినియోగదారుల కోసం మరియు ఇంటిగ్రేటెడ్ సిస్టమ్‌ల కోసం) నిర్వహించబడుతుంది. స్కీమ్‌లో ఫ్యాబ్రిక్‌ని Ethereumతో భర్తీ చేస్తున్నప్పుడు, మీరు MVCC వైరుధ్యాలను ప్రాసెస్ చేయడం నుండి అటామిక్ నాన్స్ ఇంక్రిమెంట్ మరియు రీసెండింగ్‌కు రీట్రీ సర్వీస్/డెకరేటర్ యొక్క లాజిక్‌ను మాత్రమే మార్చాలి. బఫరింగ్ మరియు స్థితి నిల్వ బ్లాక్ ఏర్పడే సమయం నుండి ప్రతిస్పందన సమయాన్ని విడదీయడం సాధ్యం చేసింది. ఇప్పుడు మీరు వేలాది ఆర్డర్ నోడ్‌లను జోడించవచ్చు మరియు బ్లాక్‌లు చాలా తరచుగా ఏర్పడతాయని మరియు ఆర్డరింగ్ సేవను లోడ్ చేస్తారని భయపడవద్దు.

ప్రాథమికంగా, నేను పంచుకోవాలనుకున్నది అంతే. ఇది వారి పనిలో ఎవరికైనా సహాయం చేస్తే నేను సంతోషిస్తాను.

మూలం: www.habr.com