வீல்செட்டுகளுக்கான விநியோகிக்கப்பட்ட பதிவு: ஹைப்பர்லெட்ஜர் துணியுடன் ஒரு அனுபவம்

வணக்கம், நான் DRD KP திட்டத்தின் குழுவில் பணிபுரிகிறேன் (சக்கர தொகுப்புகளின் வாழ்க்கை சுழற்சியை கண்காணிப்பதற்கான விநியோகிக்கப்பட்ட தரவு பதிவேட்டில்). தொழில்நுட்பக் கட்டுப்பாடுகளின் கீழ் இந்தத் திட்டத்திற்கான நிறுவன பிளாக்செயினை உருவாக்குவதில் எங்கள் குழுவின் அனுபவத்தை இங்கே பகிர்ந்து கொள்ள விரும்புகிறேன். நான் பெரும்பாலும் ஹைப்பர்லெட்ஜர் ஃபேப்ரிக் பற்றி பேசுவேன், ஆனால் இங்கு விவரிக்கப்பட்டுள்ள அணுகுமுறையை எந்த அனுமதி பெற்ற பிளாக்செயினுக்கும் விரிவுபடுத்தலாம். எங்கள் ஆராய்ச்சியின் இறுதி இலக்கு, நிறுவன பிளாக்செயின் தீர்வுகளைத் தயாரிப்பதே ஆகும், இதன் மூலம் இறுதித் தயாரிப்பு பயன்படுத்துவதற்கு இனிமையானது மற்றும் பராமரிப்பது மிகவும் கடினம் அல்ல.

கண்டுபிடிப்புகள், எதிர்பாராத தீர்வுகள் எதுவும் இருக்காது, மேலும் தனிப்பட்ட முன்னேற்றங்கள் எதுவும் இங்கு முன்னிலைப்படுத்தப்படாது (ஏனென்றால் என்னிடம் எதுவும் இல்லை). எனது சுமாரான அனுபவத்தைப் பகிர்ந்து கொள்ளவும், "இது சாத்தியம்" என்பதைக் காட்டவும், கருத்துக்களில் நல்ல மற்றும் நல்ல முடிவுகளை எடுப்பதில் மற்றவர்களின் அனுபவங்களைப் படிக்கவும் விரும்புகிறேன்.

சிக்கல்: பிளாக்செயின்கள் இன்னும் அளவிடப்படவில்லை

இன்று, பல டெவலப்பர்களின் முயற்சிகள் பிளாக்செயினை ஒரு உண்மையான வசதியான தொழில்நுட்பமாக மாற்றுவதை நோக்கமாகக் கொண்டுள்ளன, மேலும் ஒரு அழகான ரேப்பரில் டைம் பாம் அல்ல. ஸ்டேட் சேனல்கள், நம்பிக்கையான ரோல்அப், பிளாஸ்மா மற்றும் ஷார்டிங் ஆகியவை பொதுவானதாகிவிடும். சில நாள். அல்லது TON மீண்டும் வெளியீட்டை ஆறு மாதங்களுக்கு ஒத்திவைத்து, அடுத்த பிளாஸ்மா குழுமம் இல்லாமல் போகும். நாம் அடுத்த வரைபடத்தை நம்பலாம் மற்றும் இரவில் புத்திசாலித்தனமான வெள்ளைத் தாள்களைப் படிக்கலாம், ஆனால் இங்கேயும் இப்போதும் நம்மிடம் இருப்பதைக் கொண்டு ஏதாவது செய்ய வேண்டும். மலம் கழியுங்கள்.

தற்போதைய திட்டத்தில் எங்கள் குழுவிற்கு அமைக்கப்பட்டுள்ள பணி பொதுவாக இதுபோல் தெரிகிறது: பல பாடங்கள் உள்ளன, பல ஆயிரங்களை எட்டுகின்றன, அவர்கள் நம்பிக்கையில் உறவுகளை உருவாக்க விரும்பவில்லை; சிறப்பு செயல்திறன் தேவைகள் இல்லாமல் சாதாரண கணினிகளில் வேலை செய்யும் மற்றும் எந்த மையப்படுத்தப்பட்ட கணக்கியல் அமைப்புகளை விட மோசமான பயனர் அனுபவத்தை வழங்கும் DLT இல் ஒரு தீர்வை உருவாக்குவது அவசியம். தீர்வின் பின்னணியில் உள்ள தொழில்நுட்பம், தரவை தீங்கிழைக்கும் கையாளுதலின் சாத்தியத்தை குறைக்க வேண்டும் - அதனால்தான் பிளாக்செயின் இங்கே உள்ளது.

வெள்ளைத் தாள்கள் மற்றும் ஊடகங்களில் இருந்து வரும் கோஷங்கள், அடுத்த வளர்ச்சி வினாடிக்கு மில்லியன் கணக்கான பரிவர்த்தனைகளை செய்ய அனுமதிக்கும் என்று நமக்கு உறுதியளிக்கிறது. உண்மையில் அது என்ன?

Mainnet Ethereum தற்போது ~30 tps இல் இயங்குகிறது. இதன் காரணமாக மட்டும், கார்ப்பரேட் தேவைகளுக்கு ஏற்ற வகையில் பிளாக்செயினாக உணருவது கடினம். அனுமதிக்கப்பட்ட தீர்வுகளில் 2000 டிபிஎஸ் (குவாரம்) அல்லது 3000 டிபிஎஸ் (ஹைப்பர்லெட்ஜர் துணி, வெளியீட்டில் கொஞ்சம் குறைவாக உள்ளது, ஆனால் பழைய ஒருமித்த இயந்திரத்தில் அளவுகோல் மேற்கொள்ளப்பட்டது என்பதை நீங்கள் கணக்கில் எடுத்துக்கொள்ள வேண்டும்). இருந்தது தீவிர துணி செயலாக்க முயற்சி, 20000 டிபிஎஸ் மோசமான முடிவுகளைத் தரவில்லை, ஆனால் இதுவரை இது வெறும் கல்வி ஆராய்ச்சி மட்டுமே, அதன் நிலையான செயலாக்கத்திற்காக காத்திருக்கிறது. பிளாக்செயின் டெவலப்பர்களின் ஒரு துறையை பராமரிக்கக்கூடிய ஒரு நிறுவனம் அத்தகைய குறிகாட்டிகளை வைப்பது சாத்தியமில்லை. ஆனால் சிக்கல் செயல்திறன் மட்டுமல்ல, தாமதமும் உள்ளது.

தாமதத்தைத்

ஒரு பரிவர்த்தனை தொடங்கப்பட்ட தருணத்திலிருந்து கணினியின் இறுதி ஒப்புதலுக்கான தாமதமானது, சரிபார்ப்பு மற்றும் வரிசைப்படுத்துதலின் அனைத்து நிலைகளிலும் செய்தி கடந்து செல்லும் வேகத்தை மட்டுமல்ல, தொகுதி உருவாக்கம் அளவுருக்களையும் சார்ந்துள்ளது. எங்கள் பிளாக்செயின் 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 தொடர்ச்சியான நெட்வொர்க் கோரிக்கைகளையும் மறைக்கின்றன: தலைவர் பதிவில் ஒரு செய்தியைச் சேர்க்கிறார், பின்தொடர்பவர்களுக்கு அனுப்புகிறார், பிந்தையவர் அதைச் சேர்க்கிறார். அவர்களின் பதிவிற்கு, வெற்றிகரமான நகலெடுப்பின் உறுதிப்படுத்தலை தலைவருக்கு அனுப்புகிறது, தலைவர் செய்தியை அனுப்புகிறார், பின்தொடர்பவர்களுக்கு உறுதிமொழியை அனுப்புகிறார், பின்தொடர்பவர்கள் உறுதியளிக்கிறார். தொகுதி உருவாக்கத்தின் அளவு மற்றும் நேரம் சிறியது, அடிக்கடி ஆர்டர் செய்யும் சேவை ஒருமித்த கருத்தை நிறுவ வேண்டும். Hyperledger Fabric தொகுதி உருவாக்கத்திற்கான இரண்டு அளவுருக்களைக் கொண்டுள்ளது: BatchTimeout - தொகுதி உருவாக்கும் நேரம் மற்றும் BatchSize - தொகுதி அளவு (பரிவர்த்தனைகளின் எண்ணிக்கை மற்றும் தொகுதியின் அளவு பைட்டுகளில்). அளவுருக்களில் ஒன்று வரம்பை அடைந்தவுடன், ஒரு புதிய தொகுதி வெளியிடப்படுகிறது. அதிக ஆர்டர் முனைகள், இதற்கு அதிக நேரம் எடுக்கும். எனவே, நீங்கள் BatchTimeout மற்றும் BatchSize ஐ அதிகரிக்க வேண்டும். ஆனால் RWSets பதிப்பு செய்யப்பட்டுள்ளதால், நாம் உருவாக்கும் பெரிய தொகுதி, MVCC மோதல்களின் சாத்தியக்கூறுகள் அதிகம். கூடுதலாக, BatchTimeout அதிகரிக்கும் போது, ​​UX பேரழிவு தரும் வகையில் சிதைகிறது. இந்த சிக்கல்களைத் தீர்ப்பதற்கான பின்வரும் திட்டம் எனக்கு நியாயமானதாகவும் தெளிவாகவும் தெரிகிறது.

தொகுதி இறுதிக்காக காத்திருப்பதைத் தவிர்ப்பது மற்றும் பரிவர்த்தனை நிலையைக் கண்காணிக்கும் திறனை இழக்காமல் இருப்பது எப்படி

உருவாக்கும் நேரம் மற்றும் தொகுதி அளவு நீண்டது, பிளாக்செயினின் செயல்திறன் அதிகமாகும். ஒன்று மற்றொன்றிலிருந்து நேரடியாகப் பின்தொடரவில்லை, ஆனால் RAFT இல் ஒருமித்த கருத்தை நிறுவுவதற்கு, தலைவரிடமிருந்து பின்தொடர்பவர்களுக்கும் பின்னுக்கும் மூன்று நெட்வொர்க் கோரிக்கைகள் தேவை என்பதை நினைவில் கொள்ள வேண்டும். அதிக ஆர்டர் முனைகள், இதற்கு அதிக நேரம் எடுக்கும். தொகுதி உருவாக்கத்தின் அளவு மற்றும் நேரம் சிறியது, அத்தகைய தொடர்புகள் அதிகம். இறுதிப் பயனருக்கான கணினி மறுமொழி நேரத்தை அதிகரிக்காமல் தலைமுறை நேரத்தையும் தொகுதி அளவையும் அதிகரிப்பது எப்படி?

முதலில், ஒரு பெரிய தொகுதி அளவினால் ஏற்படும் MVCC முரண்பாடுகளை எப்படியாவது தீர்க்க வேண்டும், இதில் ஒரே பதிப்பில் வெவ்வேறு RWSets இருக்கலாம். வெளிப்படையாக, கிளையன்ட் பக்கத்தில் (பிளாக்செயின் நெட்வொர்க் தொடர்பாக, இது பின்தளமாக இருக்கலாம், அதாவது) உங்களுக்குத் தேவை MVCC மோதல் கையாளுபவர், இது ஒரு தனி சேவையாகவோ அல்லது அழைப்பிற்கு மேலே உள்ள வழக்கமான அலங்கரிப்பாளராகவோ இருக்கலாம், இது மீண்டும் முயற்சி தர்க்கத்துடன் பரிவர்த்தனையைத் தொடங்குகிறது.

மறுமுயற்சியை அதிவேக மூலோபாயத்துடன் செயல்படுத்தலாம், ஆனால் தாமதமானது அதிவேகமாக சிதைந்துவிடும். எனவே நீங்கள் குறிப்பிட்ட சிறிய வரம்புகளுக்குள் சீரற்ற மறு முயற்சி அல்லது நிலையான ஒன்றைப் பயன்படுத்த வேண்டும். முதல் விருப்பத்தில் சாத்தியமான மோதல்கள் மீது ஒரு கண்.

அடுத்த கட்டமாக, 15, 30 அல்லது 10000000 வினாடிகள் வரை காத்திருக்காதபடி, கணினியுடன் கிளையண்டின் தொடர்புகளை ஒத்திசைவற்றதாக ஆக்க வேண்டும், அதை நாங்கள் BatchTimeout என அமைப்போம். ஆனால் அதே நேரத்தில், பரிவர்த்தனையால் தொடங்கப்பட்ட மாற்றங்கள் பிளாக்செயினில் பதிவு செய்யப்படவில்லை என்பதை சரிபார்க்கும் திறனை பராமரிக்க வேண்டியது அவசியம்.
பரிவர்த்தனை நிலையைச் சேமிக்க ஒரு தரவுத்தளத்தைப் பயன்படுத்தலாம். எளிமையான விருப்பம் CouchDB என்பது அதன் பயன்பாட்டின் எளிமை காரணமாகும்: தரவுத்தளமானது பெட்டிக்கு வெளியே UI, ஒரு REST API ஆகியவற்றைக் கொண்டுள்ளது, மேலும் நீங்கள் எளிதாகப் பிரதி மற்றும் பகிர்வுகளை அமைக்கலாம். Fabric ஐ அதன் உலக நிலையைச் சேமிக்க பயன்படுத்தும் அதே CouchDB நிகழ்வில் நீங்கள் ஒரு தனி தொகுப்பை உருவாக்கலாம். இந்த வகையான ஆவணங்களை நாம் சேமிக்க வேண்டும்.

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

பரிவர்த்தனை சகாக்களுக்கு அனுப்பப்படுவதற்கு முன், இந்த ஆவணம் தரவுத்தளத்தில் எழுதப்பட்டது, இது ஒரு உருவாக்கும் செயல்பாடாக இருந்தால், நிறுவன ஐடி பயனருக்குத் திருப்பியளிக்கப்படும் (அதே ஐடி ஒரு விசையாகப் பயன்படுத்தப்படுகிறது), பின்னர் நிலை, TxID மற்றும் பிழை புலங்கள் தொடர்புடைய தகவல் சகாக்களிடமிருந்து பெறப்பட்டதால் புதுப்பிக்கப்பட்டது.

இந்த திட்டத்தில், பயனர் தொகுதி இறுதியாக உருவாகும் வரை காத்திருக்கவில்லை, 10 விநாடிகள் திரையில் சுழலும் சக்கரத்தைப் பார்த்து, அவர் கணினியிலிருந்து உடனடி பதிலைப் பெறுகிறார் மற்றும் தொடர்ந்து வேலை செய்கிறார்.

பரிவர்த்தனை நிலைகளைச் சேமிக்க BoltDB ஐத் தேர்ந்தெடுத்தோம், ஏனெனில் நினைவகத்தைச் சேமிக்க வேண்டும் மற்றும் ஒரு தனி தரவுத்தள சேவையகத்துடன் பிணைய தொடர்புகளில் நேரத்தை வீணடிக்க விரும்பவில்லை, குறிப்பாக எளிய உரை நெறிமுறையைப் பயன்படுத்தி இந்த தொடர்பு ஏற்படும் போது. மேலே விவரிக்கப்பட்ட திட்டத்தைச் செயல்படுத்த நீங்கள் CouchDB ஐப் பயன்படுத்தினாலும் அல்லது உலக நிலையைச் சேமிப்பதற்காக இருந்தாலும், CouchDB இல் தரவுச் சேமிக்கப்படும் முறையை மேம்படுத்துவது அர்த்தமுள்ளதாக இருக்கும். இயல்பாக, CouchDB இல், b-tree nodes அளவு 1279 பைட்டுகள் ஆகும், இது வட்டில் உள்ள துறை அளவை விட மிகவும் சிறியது, அதாவது மரத்தைப் படிப்பது மற்றும் மறுசீரமைப்பது ஆகிய இரண்டிற்கும் வட்டுக்கு அதிக உடல் அணுகல் தேவைப்படும். உகந்த அளவு தரநிலைக்கு ஒத்திருக்கிறது மேம்பட்ட வடிவம் மற்றும் 4 கிலோபைட் ஆகும். மேம்படுத்த, நாம் அளவுருவை அமைக்க வேண்டும் btree_chunk_size 4096க்கு சமம் CouchDB உள்ளமைவு கோப்பில். BoltDB போன்ற கைமுறை தலையீடு தேவையில்லை.

பின் அழுத்தம்: தாங்கல் உத்தி

ஆனால் நிறைய செய்திகள் இருக்கலாம். கணினி கையாளக்கூடியதை விட, வரைபடத்தில் காட்டப்பட்டுள்ளதைத் தவிர ஒரு டஜன் பிற சேவைகளுடன் வளங்களைப் பகிர்வது - மேலும் இவை அனைத்தும் இன்டெல்லிஜ் ஐடியாவை இயக்குவது மிகவும் கடினமான கணினிகளில் கூட குறைபாடற்ற முறையில் செயல்பட வேண்டும்.

தகவல்தொடர்பு அமைப்புகளின் வெவ்வேறு திறன்களின் சிக்கல், தயாரிப்பாளர் மற்றும் நுகர்வோர், வெவ்வேறு வழிகளில் தீர்க்கப்படுகிறது. என்ன செய்யலாம் என்று பார்க்கலாம்.

கைவிடுவது: அதிகபட்சம் X பரிவர்த்தனைகளை T வினாடிகளில் செயல்படுத்தும் திறன் கொண்டவர்கள் என்று நாம் கூறலாம். இந்த வரம்பை மீறும் அனைத்து கோரிக்கைகளும் நிராகரிக்கப்படும். இது மிகவும் எளிமையானது, ஆனால் நீங்கள் UX பற்றி மறந்துவிடலாம்.

கட்டுப்படுத்தும்: நுகர்வோர் சில வகையான இடைமுகத்தைக் கொண்டிருக்க வேண்டும், இதன் மூலம் சுமையைப் பொறுத்து, அவர் தயாரிப்பாளரின் TPS ஐக் கட்டுப்படுத்த முடியும். மோசமாக இல்லை, ஆனால் இந்த இடைமுகத்தை செயல்படுத்த சுமைகளை உருவாக்கும் கிளையண்டின் டெவலப்பர்கள் மீது இது கடமைகளை சுமத்துகிறது. இது எங்களுக்கு ஏற்றுக்கொள்ள முடியாதது, ஏனெனில் பிளாக்செயின் எதிர்காலத்தில் அதிக எண்ணிக்கையிலான நீண்டகால அமைப்புகளில் ஒருங்கிணைக்கப்படும்.

இடையக: உள்ளீட்டு தரவு ஸ்ட்ரீமை எதிர்ப்பதற்குப் பதிலாக, இந்த ஸ்ட்ரீமை இடையகப்படுத்தி தேவையான வேகத்தில் செயலாக்கலாம். நாம் ஒரு நல்ல பயனர் அனுபவத்தை வழங்க விரும்பினால், வெளிப்படையாக இதுவே சிறந்த தீர்வாகும். RabbitMQ இல் வரிசையைப் பயன்படுத்தி இடையகத்தைச் செயல்படுத்தினோம்.

திட்டத்தில் இரண்டு புதிய செயல்கள் சேர்க்கப்பட்டுள்ளன: (1) APIக்கான கோரிக்கை வந்த பிறகு, ஒரு பரிவர்த்தனையை அழைப்பதற்குத் தேவையான அளவுருக்கள் கொண்ட செய்தி வரிசையில் வைக்கப்படும், மேலும் வாடிக்கையாளர் பரிவர்த்தனை ஏற்றுக்கொள்ளப்பட்ட செய்தியைப் பெறுகிறார். அமைப்பு, (2) பின்தளமானது வரிசையில் இருந்து கட்டமைப்பில் குறிப்பிடப்பட்ட வேகத்தில் தரவைப் படிக்கிறது; ஸ்டேட்டஸ் ஸ்டோரில் பரிவர்த்தனையைத் தொடங்கி தரவைப் புதுப்பிக்கிறது.
இப்போது நீங்கள் உருவாக்கும் நேரத்தை அதிகரிக்கலாம் மற்றும் பயனரின் தாமதங்களை மறைத்து, நீங்கள் விரும்பும் அளவுக்கு திறனைத் தடுக்கலாம்.

பிற கருவிகள்

செயின்கோட் பற்றி இங்கு எதுவும் கூறப்படவில்லை, ஏனெனில், ஒரு விதியாக, அதில் மேம்படுத்த எதுவும் இல்லை. செயின்கோட் முடிந்தவரை எளிமையாகவும் பாதுகாப்பாகவும் இருக்க வேண்டும் - அதற்குத் தேவையானது அவ்வளவுதான். கட்டமைப்பானது சங்கிலி குறியீட்டை எளிமையாகவும் பாதுகாப்பாகவும் எழுத உதவுகிறது CCKit S7 Techlab மற்றும் நிலையான பகுப்பாய்வியிலிருந்து புத்துயிர் ^ CC.

கூடுதலாக, எங்கள் குழு ஃபேப்ரிக் உடன் வேலை செய்வதை எளிமையாகவும் சுவாரஸ்யமாகவும் மாற்றுவதற்கு ஒரு தொகுப்பை உருவாக்கி வருகிறது: பிளாக்செயின் எக்ஸ்ப்ளோரர், ஒரு பயன்பாடு தானியங்கி பிணைய கட்டமைப்பு மாற்றங்கள் (நிறுவனங்களைச் சேர்த்தல்/அகற்றுதல், RAFT முனைகள்), இதற்கான பயன்பாடு சான்றிதழ்களை ரத்து செய்தல் மற்றும் அடையாளத்தை நீக்குதல். நீங்கள் பங்களிக்க விரும்பினால், உங்களை வரவேற்கிறோம்.

முடிவுக்கு

இந்த அணுகுமுறை Hyperledger Fabric ஐ Quorum, பிற தனியார் Ethereum நெட்வொர்க்குகள் (PoA அல்லது PoW) மூலம் எளிதாக மாற்ற அனுமதிக்கிறது, உண்மையான செயல்திறனை கணிசமாகக் குறைக்கிறது, ஆனால் அதே நேரத்தில் சாதாரண UX ஐ பராமரிக்கவும் (உலாவியில் உள்ள பயனர்கள் மற்றும் ஒருங்கிணைந்த அமைப்புகளுக்கு). திட்டத்தில் Fabric ஐ Ethereum உடன் மாற்றும் போது, ​​MVCC மோதல்களைச் செயலாக்குவதில் இருந்து அணுக்கரு அதிகரிப்பு மற்றும் மறுபரிசீலனைக்கு மறுமுயற்சி சேவை/அலங்கரிப்பாளரின் தர்க்கத்தை மட்டுமே நீங்கள் மாற்ற வேண்டும். இடையகப்படுத்தல் மற்றும் நிலை சேமிப்பகமானது, பிளாக் உருவாக்கும் நேரத்திலிருந்து மறுமொழி நேரத்தை துண்டிப்பதை சாத்தியமாக்கியது. இப்போது நீங்கள் ஆயிரக்கணக்கான ஆர்டர் முனைகளைச் சேர்க்கலாம் மற்றும் தொகுதிகள் அடிக்கடி உருவாகின்றன மற்றும் ஆர்டர் செய்யும் சேவையை ஏற்றலாம் என்று பயப்பட வேண்டாம்.

அடிப்படையில், நான் பகிர்ந்து கொள்ள விரும்பியது அவ்வளவுதான். இது ஒருவரின் வேலையில் உதவியிருந்தால் நான் மகிழ்ச்சியடைவேன்.

ஆதாரம்: www.habr.com