🥇பொது சோதனை: Ethereum இல் தனியுரிமை மற்றும் அளவிடுதல் ஒரு தீர்வு

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

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

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

பிளாஸ்மா பணத்தில் முக்கிய செயல்முறைகள்

1. பிளாஸ்மா கேஷ் டோக்கனில் டெபாசிட் செய்ய விரும்பும் ETH இன் அளவைப் பயனர் ஸ்மார்ட் ஒப்பந்தச் செயல்பாட்டை `டெபாசிட்` என்று அழைக்கிறார். ஸ்மார்ட் ஒப்பந்த செயல்பாடு ஒரு டோக்கனை உருவாக்குகிறது மற்றும் அதைப் பற்றிய நிகழ்வை உருவாக்குகிறது.

2. ஸ்மார்ட் காண்ட்ராக்ட் நிகழ்வுகளுக்கு சந்தா செலுத்திய பிளாஸ்மா கேஷ் நோட்கள் டெபாசிட் உருவாக்குவது பற்றிய நிகழ்வைப் பெறுகின்றன மற்றும் பூலுக்கு டோக்கனை உருவாக்குவது பற்றிய பரிவர்த்தனையைச் சேர்க்கின்றன.

3. குறிப்பிட்ட கால இடைவெளியில், சிறப்பு பிளாஸ்மா பண முனைகள் குளத்தில் இருந்து அனைத்து பரிவர்த்தனைகளையும் (1 மில்லியன் வரை) எடுத்து அவற்றிலிருந்து ஒரு தொகுதியை உருவாக்கி, மெர்கில் மரத்தை கணக்கிட்டு, அதன்படி, ஹாஷ். சரிபார்ப்பதற்காக இந்தத் தொகுதி மற்ற முனைகளுக்கு அனுப்பப்படுகிறது. Merkle ஹாஷ் செல்லுபடியாகுமா மற்றும் பரிவர்த்தனைகள் செல்லுபடியாகுமா என்பதை முனைகள் சரிபார்க்கின்றன (உதாரணமாக, டோக்கனை அனுப்புபவர் அதன் உரிமையாளரா). தடுப்பைச் சரிபார்த்த பிறகு, ஸ்மார்ட் ஒப்பந்தத்தின் `submitBlock' செயல்பாட்டை முனை அழைக்கிறது, இது பிளாக் எண்ணையும் Merkle ஹாஷையும் விளிம்புச் சங்கிலியில் சேமிக்கிறது. ஸ்மார்ட் ஒப்பந்தமானது ஒரு தொகுதியை வெற்றிகரமாகச் சேர்ப்பதைக் குறிக்கும் நிகழ்வை உருவாக்குகிறது. குளத்திலிருந்து பரிவர்த்தனைகள் அகற்றப்பட்டன.

4. தொகுதி சமர்ப்பிப்பு நிகழ்வைப் பெறும் முனைகள் தொகுதியில் சேர்க்கப்பட்ட பரிவர்த்தனைகளைப் பயன்படுத்தத் தொடங்குகின்றன.

5. ஒரு கட்டத்தில், டோக்கனின் உரிமையாளர் (அல்லது உரிமையாளர் அல்லாதவர்) அதை பிளாஸ்மா பணத்திலிருந்து திரும்பப் பெற விரும்புகிறார். இதைச் செய்ய, அவர் `ஸ்டார்ட்எக்சிட்` செயல்பாட்டை அழைக்கிறார், டோக்கனில் உள்ள கடைசி 2 பரிவர்த்தனைகள் பற்றிய தகவலை அதில் அனுப்புகிறார், இது அவர் டோக்கனின் உரிமையாளர் என்பதை உறுதிப்படுத்துகிறது. ஸ்மார்ட் ஒப்பந்தம், Merkle ஹாஷைப் பயன்படுத்தி, தொகுதிகளில் பரிவர்த்தனைகள் இருப்பதைச் சரிபார்த்து, திரும்பப் பெறுவதற்கான டோக்கனை அனுப்புகிறது, இது இரண்டு வாரங்களில் நிகழும்.

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

தனியுரிமை இரண்டு வழிகளில் அடையப்படுகிறது

1. குழந்தைச் சங்கிலிக்குள் உருவாக்கப்பட்ட மற்றும் அனுப்பப்படும் பரிவர்த்தனைகள் பற்றி ரூட் செயினுக்கு எதுவும் தெரியாது. பிளாஸ்மா கேஷிலிருந்து ETH டெபாசிட் செய்து திரும்பப் பெற்றவர்கள் பற்றிய தகவல் பொதுவில் உள்ளது.

2. சைல்டு செயின் zk-SNARKகளைப் பயன்படுத்தி அநாமதேய பரிவர்த்தனைகளை அனுமதிக்கிறது.

தொழில்நுட்ப அடுக்கு

NodeJS
Redis
etherium
மண்

சோதனை

Plasma Cash ஐ உருவாக்கும் போது, கணினியின் வேகத்தை நாங்கள் சோதித்து பின்வரும் முடிவுகளைப் பெற்றோம்:

வினாடிக்கு 35 பரிவர்த்தனைகள் வரை குளத்தில் சேர்க்கப்படுகின்றன;
ஒரு தொகுதியில் 1 பரிவர்த்தனைகள் வரை சேமிக்க முடியும்.

பின்வரும் 3 சேவையகங்களில் சோதனைகள் மேற்கொள்ளப்பட்டன:

1. இன்டெல் கோர் i7-6700 குவாட்-கோர் ஸ்கைலேக் உட்பட. NVMe SSD - 512 GB, 64 GB DDR4 ரேம்
3 சரிபார்க்கும் பிளாஸ்மா பண முனைகள் உயர்த்தப்பட்டன.

2. AMD Ryzen 7 1700X Octa-Core "Summit Ridge" (Zen), SATA SSD - 500 GB, 64 GB DDR4 ரேம்
Ropsten testnet ETH முனை உயர்த்தப்பட்டது.
3 சரிபார்க்கும் பிளாஸ்மா பண முனைகள் உயர்த்தப்பட்டன.

3. இன்டெல் கோர் i9-9900K ஆக்டா-கோர் உட்பட. NVMe SSD - 1 TB, 64 GB DDR4 ரேம்
1 பிளாஸ்மா பணச் சமர்ப்பிப்பு முனை உயர்த்தப்பட்டது.
3 சரிபார்க்கும் பிளாஸ்மா பண முனைகள் உயர்த்தப்பட்டன.
பிளாஸ்மா கேஷ் நெட்வொர்க்கில் பரிவர்த்தனைகளைச் சேர்க்க ஒரு சோதனை தொடங்கப்பட்டது.

மொத்தம்: ஒரு தனியார் நெட்வொர்க்கில் 10 பிளாஸ்மா பண முனைகள்.

சோதனை 1

ஒரு தொகுதிக்கு 1 மில்லியன் பரிவர்த்தனைகள் என்ற வரம்பு உள்ளது. எனவே, 1 மில்லியன் பரிவர்த்தனைகள் 2 தொகுதிகளாக விழும் (கணினி பரிவர்த்தனைகளில் ஒரு பகுதியை எடுத்து அவற்றை அனுப்பும் போது சமர்ப்பிக்க நிர்வகிக்கிறது).

ஆரம்ப நிலை: கடைசி தொகுதி #7; 1 மில்லியன் பரிவர்த்தனைகள் மற்றும் டோக்கன்கள் தரவுத்தளத்தில் சேமிக்கப்பட்டுள்ளன.

00:00 — பரிவர்த்தனை உருவாக்க ஸ்கிரிப்ட்டின் தொடக்கம்
01:37 - 1 மில்லியன் பரிவர்த்தனைகள் உருவாக்கப்பட்டு முனைக்கு அனுப்புவது தொடங்கியது
01:46 — சமர்ப்பி முனை பூல் மற்றும் படிவங்கள் தொகுதி #240ல் இருந்து 8k பரிவர்த்தனைகளை எடுத்தது. 320 வினாடிகளில் 10k பரிவர்த்தனைகள் குளத்தில் சேர்க்கப்படுவதையும் காண்கிறோம்
01:58 — தொகுதி #8 கையொப்பமிடப்பட்டு சரிபார்ப்பிற்காக அனுப்பப்பட்டது
02:03 — தொகுதி #8 சரிபார்க்கப்பட்டது மற்றும் ஸ்மார்ட் ஒப்பந்தத்தின் `submitBlock' செயல்பாடு Merkle ஹாஷ் மற்றும் பிளாக் எண்ணுடன் அழைக்கப்படுகிறது.
02:10 — டெமோ ஸ்கிரிப்ட் வேலை முடிந்தது, இது 1 வினாடிகளில் 32 மில்லியன் பரிவர்த்தனைகளை அனுப்பியது
02:33 - ரூட் செயினில் பிளாக் #8 சேர்க்கப்பட்டு, 240k பரிவர்த்தனைகளைச் செய்யத் தொடங்கியது என்ற தகவலை முனைகள் பெறத் தொடங்கின.
02:40 - 240k பரிவர்த்தனைகள் குளத்திலிருந்து அகற்றப்பட்டன, அவை ஏற்கனவே தொகுதி #8 இல் உள்ளன
02:56 — submit node மீதமுள்ள 760k பரிவர்த்தனைகளை பூலில் இருந்து எடுத்து, Merkle ஹாஷ் மற்றும் பிளாக் #9 கையொப்பத்தை கணக்கிட ஆரம்பித்தது.
03:20 - அனைத்து முனைகளிலும் 1 மில்லியன் 240k பரிவர்த்தனைகள் மற்றும் டோக்கன்கள் உள்ளன
03:35 — பிளாக் #9 கையொப்பமிடப்பட்டு மற்ற முனைகளுக்கு சரிபார்ப்புக்காக அனுப்பப்பட்டது
03:41 - நெட்வொர்க் பிழை ஏற்பட்டது
04:40 — தொகுதி #9 சரிபார்ப்புக்கான காத்திருப்பு நேரம் முடிந்தது
04:54 — submit node மீதமுள்ள 760k பரிவர்த்தனைகளை பூலில் இருந்து எடுத்து, Merkle ஹாஷ் மற்றும் பிளாக் #9 கையொப்பத்தை கணக்கிட ஆரம்பித்தது.
05:32 — பிளாக் #9 கையொப்பமிடப்பட்டு மற்ற முனைகளுக்கு சரிபார்ப்புக்காக அனுப்பப்பட்டது
05:53 — தொகுதி #9 சரிபார்க்கப்பட்டு ரூட் செயினுக்கு அனுப்பப்பட்டது
06:17 - ரூட் செயினில் பிளாக் #9 சேர்க்கப்பட்டு 760k பரிவர்த்தனைகளைச் செய்யத் தொடங்கியது என்ற தகவலை நோட்கள் பெறத் தொடங்கின.
06:47 — தொகுதி #9 இல் உள்ள பரிவர்த்தனைகளை பூல் நீக்கியுள்ளது
09:06 - அனைத்து முனைகளிலும் 2 மில்லியன் பரிவர்த்தனைகள் மற்றும் டோக்கன்கள் உள்ளன

சோதனை 2

ஒரு தொகுதிக்கு 350k வரம்பு உள்ளது. இதன் விளைவாக, எங்களுக்கு 3 தொகுதிகள் உள்ளன.

ஆரம்ப நிலை: கடைசி தொகுதி #9; 2 மில்லியன் பரிவர்த்தனைகள் மற்றும் டோக்கன்கள் தரவுத்தளத்தில் சேமிக்கப்பட்டுள்ளன

00:00 — பரிவர்த்தனை தலைமுறை ஸ்கிரிப்ட் ஏற்கனவே தொடங்கப்பட்டது
00:44 - 1 மில்லியன் பரிவர்த்தனைகள் உருவாக்கப்பட்டு முனைக்கு அனுப்புவது தொடங்கியது
00:56 — சமர்ப்பி முனை பூல் மற்றும் படிவங்கள் தொகுதி #320ல் இருந்து 10k பரிவர்த்தனைகளை எடுத்தது. 320 வினாடிகளில் 10k பரிவர்த்தனைகள் குளத்தில் சேர்க்கப்படுவதையும் காண்கிறோம்
01:12 — தொகுதி #10 கையொப்பமிடப்பட்டு, சரிபார்ப்பிற்காக மற்ற முனைகளுக்கு அனுப்பப்பட்டது
01:18 — டெமோ ஸ்கிரிப்ட் வேலை முடிந்தது, இது 1 வினாடிகளில் 34 மில்லியன் பரிவர்த்தனைகளை அனுப்பியது
01:20 — தொகுதி #10 சரிபார்க்கப்பட்டு ரூட் செயினுக்கு அனுப்பப்பட்டது
01:51 - பிளாக் #10 சேர்க்கப்பட்டு 320k பரிவர்த்தனைகளைப் பயன்படுத்தத் தொடங்கும் ரூட் சங்கிலியிலிருந்து அனைத்து முனைகளும் தகவலைப் பெற்றன.
02:01 - பிளாக் #320 இல் சேர்க்கப்பட்ட 10 ஆயிரம் பரிவர்த்தனைகளுக்கு குளம் அழிக்கப்பட்டது
02:15 — சமர்ப்பி முனை பூல் மற்றும் படிவங்கள் தொகுதி #350ல் இருந்து 11k பரிவர்த்தனைகளை எடுத்தது
02:34 — தொகுதி #11 கையொப்பமிடப்பட்டு, சரிபார்ப்பிற்காக மற்ற முனைகளுக்கு அனுப்பப்பட்டது
02:51 — தொகுதி #11 சரிபார்க்கப்பட்டு ரூட் சங்கிலிக்கு அனுப்பப்பட்டது
02:55 — பிளாக் #10ல் இருந்து பரிவர்த்தனைகளை முடித்த கடைசி முனை
10:59 — பிளாக் #9 ஐ சமர்ப்பிப்பதன் மூலம் பரிவர்த்தனை ரூட் சங்கிலியில் மிக நீண்ட நேரம் எடுத்தது, ஆனால் அது முடிந்தது மற்றும் அனைத்து முனைகளும் அதைப் பற்றிய தகவலைப் பெற்று 350k பரிவர்த்தனைகளைச் செய்யத் தொடங்கின.
11:05 - பிளாக் #320 இல் சேர்க்கப்பட்ட 11 ஆயிரம் பரிவர்த்தனைகளுக்கு குளம் அழிக்கப்பட்டது
12:10 - அனைத்து முனைகளிலும் 1 மில்லியன் 670k பரிவர்த்தனைகள் மற்றும் டோக்கன்கள் உள்ளன
12:17 — சமர்ப்பி முனை பூல் மற்றும் படிவங்கள் தொகுதி #330ல் இருந்து 12k பரிவர்த்தனைகளை எடுத்தது
12:32 — தொகுதி #12 கையொப்பமிடப்பட்டு, சரிபார்ப்பிற்காக மற்ற முனைகளுக்கு அனுப்பப்பட்டது
12:39 — தொகுதி #12 சரிபார்க்கப்பட்டு ரூட் செயினுக்கு அனுப்பப்பட்டது
13:44 - பிளாக் #12 சேர்க்கப்பட்டு 330k பரிவர்த்தனைகளைப் பயன்படுத்தத் தொடங்கும் ரூட் சங்கிலியிலிருந்து அனைத்து முனைகளும் தகவலைப் பெற்றன.
14:50 - அனைத்து முனைகளிலும் 2 மில்லியன் பரிவர்த்தனைகள் மற்றும் டோக்கன்கள் உள்ளன

சோதனை 3

முதல் மற்றும் இரண்டாவது சேவையகங்களில், ஒரு சரிபார்க்கும் முனை சமர்பிக்கும் முனையால் மாற்றப்பட்டது.

ஆரம்ப நிலை: கடைசி தொகுதி #84; 0 பரிவர்த்தனைகள் மற்றும் டோக்கன்கள் தரவுத்தளத்தில் சேமிக்கப்பட்டுள்ளன

00:00 — ஒவ்வொன்றும் 3 மில்லியன் பரிவர்த்தனைகளை உருவாக்கி அனுப்பும் 1 ஸ்கிரிப்ட்கள் தொடங்கப்பட்டுள்ளன
01:38 — 1 மில்லியன் பரிவர்த்தனைகள் உருவாக்கப்பட்டு, சமர்ப்பிப்பு முனை #3க்கு அனுப்புதல் தொடங்கியது
01:50 — சமர்ப்பி முனை #3 பூல் மற்றும் படிவங்கள் தொகுதி #330 (f85) இலிருந்து 21k பரிவர்த்தனைகளை எடுத்தது. 350 வினாடிகளில் 10k பரிவர்த்தனைகள் குளத்தில் சேர்க்கப்படுவதையும் காண்கிறோம்
01:53 — 1 மில்லியன் பரிவர்த்தனைகள் உருவாக்கப்பட்டு, சமர்ப்பிப்பு முனை #1க்கு அனுப்புதல் தொடங்கியது
01:50 — சமர்ப்பி முனை #3 பூல் மற்றும் படிவங்கள் தொகுதி #330 (f85) இலிருந்து 21k பரிவர்த்தனைகளை எடுத்தது. 350 வினாடிகளில் 10k பரிவர்த்தனைகள் குளத்தில் சேர்க்கப்படுவதையும் காண்கிறோம்
02:01 — சமர்ப்பி முனை #1 பூலில் இருந்து 250 பரிவர்த்தனைகளை எடுத்தது மற்றும் படிவங்கள் தொகுதி #85 (65e)
02:06 — தொகுதி #85 (f21) கையொப்பமிடப்பட்டு, சரிபார்ப்பிற்காக மற்ற முனைகளுக்கு அனுப்பப்பட்டது
02:08 — சர்வர் #3 இன் டெமோ ஸ்கிரிப்ட், 1 வினாடிகளில் 30 மில்லியன் பரிவர்த்தனைகளை அனுப்பியது, வேலை முடிந்தது
02:14 — தொகுதி #85 (f21) சரிபார்க்கப்பட்டு ரூட் சங்கிலிக்கு அனுப்பப்பட்டது
02:19 — தொகுதி #85 (65e) கையொப்பமிடப்பட்டு, சரிபார்ப்பிற்காக மற்ற முனைகளுக்கு அனுப்பப்பட்டது
02:22 — 1 மில்லியன் பரிவர்த்தனைகள் உருவாக்கப்பட்டு, சமர்ப்பிப்பு முனை #2க்கு அனுப்புதல் தொடங்கியது
02:27 — தொகுதி #85 (65e) சரிபார்க்கப்பட்டு ரூட் செயினுக்கு அனுப்பப்பட்டது
02:29 — சமர்ப்பி முனை #2 பூலில் இருந்து 111855 பரிவர்த்தனைகளை எடுத்தது மற்றும் படிவங்கள் தொகுதி #85 (256).
02:36 — பிளாக் #85 (256) கையொப்பமிடப்பட்டு சரிபார்ப்பிற்காக மற்ற முனைகளுக்கு அனுப்பப்பட்டது
02:36 — சர்வர் #1 இன் டெமோ ஸ்கிரிப்ட், 1 வினாடிகளில் 42.5 மில்லியன் பரிவர்த்தனைகளை அனுப்பியது, வேலை முடிந்தது
02:38 — தொகுதி #85 (256) சரிபார்க்கப்பட்டு ரூட் செயினுக்கு அனுப்பப்பட்டது
03:08 — சர்வர் #2 ஸ்கிரிப்ட் வேலை முடிந்தது, இது 1 வினாடிகளில் 47 மில்லியன் பரிவர்த்தனைகளை அனுப்பியது
03:38 - #85 (f21), #86(65e), #87(256) ஐத் தடுக்கும் ரூட் செயினிலிருந்து அனைத்து முனைகளும் தகவலைப் பெற்றன
03:49 - #330 (f250), #111855(85e), #21(86) தொகுதிகளில் சேர்க்கப்பட்ட 65k, 87k, 256 பரிவர்த்தனைகளில் குளம் அழிக்கப்பட்டது.
03:59 — சமர்ப்பிப்பு node #1 பூல் மற்றும் படிவங்கள் #888145 (88) 214 பரிவர்த்தனைகளை எடுத்தது, சமர்ப்பிப்பு node #2 பூலில் இருந்து 750k பரிவர்த்தனைகளை எடுத்தது மற்றும் படிவங்கள் #88 (50a), சமர்ப்பிப்பு node #3 இலிருந்து 670k பரிவர்த்தனைகளை எடுத்தது குளம் மற்றும் படிவங்கள் தொகுதி #88 (d3b)
04:44 — தொகுதி #88 (d3b) கையொப்பமிடப்பட்டு, சரிபார்ப்பிற்காக மற்ற முனைகளுக்கு அனுப்பப்பட்டது
04:58 — பிளாக் #88 (214) கையொப்பமிடப்பட்டு சரிபார்ப்பிற்காக மற்ற முனைகளுக்கு அனுப்பப்பட்டது
05:11 — தொகுதி #88 (50a) கையொப்பமிடப்பட்டு, சரிபார்ப்பிற்காக மற்ற முனைகளுக்கு அனுப்பப்பட்டது
05:11 — தொகுதி #85 (d3b) சரிபார்க்கப்பட்டு ரூட் சங்கிலிக்கு அனுப்பப்பட்டது
05:36 — தொகுதி #85 (214) சரிபார்க்கப்பட்டு ரூட் செயினுக்கு அனுப்பப்பட்டது
05:43 - #88 (d3b), #89(214) தொகுதிகள் சேர்க்கப்பட்டு 670k, 750k பரிவர்த்தனைகளைப் பயன்படுத்தத் தொடங்கும் ரூட் செயினிலிருந்து அனைத்து முனைகளும் தகவலைப் பெற்றன.
06:50 — தகவல் தொடர்பு தோல்வி காரணமாக, #85 (50a) தொகுதி சரிபார்க்கப்படவில்லை
06:55 — சமர்ப்பி முனை #2 பூலில் இருந்து 888145 பரிவர்த்தனைகளை எடுத்தது மற்றும் படிவங்கள் தொகுதி #90 (50a)
08:14 — தொகுதி #90 (50a) கையொப்பமிடப்பட்டு, சரிபார்ப்பிற்காக மற்ற முனைகளுக்கு அனுப்பப்பட்டது
09:04 — தொகுதி #90 (50a) சரிபார்க்கப்பட்டு ரூட் சங்கிலிக்கு அனுப்பப்பட்டது
11:23 - #90 (50a) தொகுதி சேர்க்கப்பட்டு, 888145 பரிவர்த்தனைகளைப் பயன்படுத்தத் தொடங்கும் ரூட் சங்கிலியிலிருந்து அனைத்து முனைகளும் தகவலைப் பெற்றன. அதே நேரத்தில், சேவையகம் #3 ஏற்கனவே தொகுதிகள் #88 (d3b), #89(214) பரிவர்த்தனைகளைப் பயன்படுத்தியுள்ளது
12:11 - அனைத்து குளங்களும் காலியாக உள்ளன
13:41 — சர்வர் #3 இன் அனைத்து முனைகளிலும் 3 மில்லியன் பரிவர்த்தனைகள் மற்றும் டோக்கன்கள் உள்ளன
14:35 — சர்வர் #1 இன் அனைத்து முனைகளிலும் 3 மில்லியன் பரிவர்த்தனைகள் மற்றும் டோக்கன்கள் உள்ளன
19:24 — சர்வர் #2 இன் அனைத்து முனைகளிலும் 3 மில்லியன் பரிவர்த்தனைகள் மற்றும் டோக்கன்கள் உள்ளன

தடைகள்

பிளாஸ்மா பணத்தின் வளர்ச்சியின் போது, பின்வரும் சிக்கல்களை நாங்கள் எதிர்கொண்டோம், அதை நாங்கள் படிப்படியாக தீர்த்து தீர்க்கிறோம்:

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

2. தரவு பரிமாற்றச் செலவுகளைக் குறைக்கும் போது, அதிக எண்ணிக்கையிலான பரிவர்த்தனைகளை எவ்வாறு அனுப்புவது என்பது உடனடியாகத் தெரியவில்லை.

3. உயர் முடிவுகளை அடைவதற்கு எப்படி, எங்கு தரவைச் சேமிப்பது என்பது தெளிவாகத் தெரியவில்லை.

4. 1 மில்லியன் பரிவர்த்தனைகளைக் கொண்ட ஒரு தொகுதியின் அளவு சுமார் 100 MB வரை எடுக்கும் என்பதால், கணுக்களுக்கு இடையில் ஒரு பிணையத்தை எவ்வாறு ஒழுங்கமைப்பது என்பது தெளிவாகத் தெரியவில்லை.

5. ஒற்றை-திரிக்கப்பட்ட பயன்முறையில் வேலை செய்வது நீண்ட கணக்கீடுகள் நிகழும்போது முனைகளுக்கு இடையிலான தொடர்பை உடைக்கிறது (உதாரணமாக, ஒரு மெர்கில் மரத்தை உருவாக்கி அதன் ஹாஷைக் கணக்கிடுதல்).

இதையெல்லாம் நாங்கள் எப்படி எதிர்கொண்டோம்?

பிளாஸ்மா கேஷ் நோட்டின் முதல் பதிப்பு, ஒரே நேரத்தில் அனைத்தையும் செய்யக்கூடிய ஒரு வகையான கலவையாகும்: பரிவர்த்தனைகளை ஏற்றுக்கொள்வது, தொகுதிகளைச் சமர்ப்பித்தல் மற்றும் சரிபார்த்தல் மற்றும் தரவை அணுகுவதற்கான API ஐ வழங்குதல். NodeJS பூர்வீகமாக ஒற்றை-திரிக்கப்பட்டதாக இருப்பதால், ஹெவி மெர்க்கல் ட்ரீ கணக்கீடு செயல்பாடு சேர் பரிவர்த்தனை செயல்பாட்டைத் தடுத்தது. இந்த சிக்கலை தீர்க்க இரண்டு விருப்பங்களை நாங்கள் கண்டோம்:

1. பல NodeJS செயல்முறைகளைத் தொடங்கவும், அவை ஒவ்வொன்றும் குறிப்பிட்ட செயல்பாடுகளைச் செய்கின்றன.

2. worker_threads ஐப் பயன்படுத்தி, குறியீட்டின் ஒரு பகுதியைத் தொடரிழைகளாக நகர்த்தவும்.

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

1. சமர்ப்பிப்பு முனை, இது குளத்தில் பரிவர்த்தனைகளை ஏற்றுக்கொண்டு தொகுதிகளை உருவாக்குகிறது.

2. முனைகளின் செல்லுபடியை சரிபார்க்கும் சரிபார்ப்பு முனை.

3. API முனை - தரவை அணுகுவதற்கான API ஐ வழங்குகிறது.

இந்த வழக்கில், யூனிக்ஸ் சாக்கெட் வழியாக கிளியைப் பயன்படுத்தி ஒவ்வொரு முனையுடனும் இணைக்கலாம்.

மெர்கல் மரத்தை கணக்கிடுவது போன்ற கனமான செயல்பாடுகளை தனி நூலாக மாற்றினோம்.

இவ்வாறு, அனைத்து பிளாஸ்மா பண செயல்பாடுகளின் இயல்பான செயல்பாட்டை ஒரே நேரத்தில் மற்றும் தோல்விகள் இல்லாமல் அடைந்துள்ளோம்.

கணினி செயல்பட்டதும், வேகத்தைச் சோதிக்கத் தொடங்கினோம், துரதிர்ஷ்டவசமாக, திருப்தியற்ற முடிவுகளைப் பெற்றோம்: வினாடிக்கு 5 பரிவர்த்தனைகள் மற்றும் ஒரு தொகுதிக்கு 000 பரிவர்த்தனைகள். தவறாக செயல்படுத்தப்பட்டதை நான் கண்டுபிடிக்க வேண்டியிருந்தது.

தொடங்குவதற்கு, கணினியின் உச்ச திறனைக் கண்டறிய பிளாஸ்மா பணத்துடன் தொடர்பு கொள்ளும் பொறிமுறையை நாங்கள் சோதிக்கத் தொடங்கினோம். பிளாஸ்மா கேஷ் நோட் ஒரு யூனிக்ஸ் சாக்கெட் இடைமுகத்தை வழங்குகிறது என்று நாங்கள் முன்பே எழுதினோம். ஆரம்பத்தில் இது உரை அடிப்படையிலானது. json பொருள்கள் `JSON.parse()` மற்றும் `JSON.stringify()` ஆகியவற்றைப் பயன்படுத்தி அனுப்பப்பட்டன.

```json
{
  "action": "sendTransaction",
  "payload":{
    "prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
    "prevBlock": 41,
    "tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
    "newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
    "type": "pay",
    "data": "",
    "signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
  }
}
```

அத்தகைய பொருட்களின் பரிமாற்ற வேகத்தை நாங்கள் அளந்தோம் மற்றும் வினாடிக்கு ~ 130k கண்டோம். json உடன் பணிபுரிவதற்கான நிலையான செயல்பாடுகளை மாற்ற முயற்சித்தோம், ஆனால் செயல்திறன் மேம்படவில்லை. இந்த செயல்பாடுகளுக்கு V8 இன்ஜின் நன்கு உகந்ததாக இருக்க வேண்டும்.

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

தரவுத்தளத்தில் பதிவு செய்தல்

ஆரம்பத்தில், எங்கள் தேவைகளைப் பூர்த்தி செய்யும் மிகவும் பயனுள்ள தீர்வுகளில் ஒன்றாக தரவு சேமிப்பிற்காக ரெடிஸ் தேர்ந்தெடுக்கப்பட்டது: முக்கிய மதிப்பு சேமிப்பு, ஹாஷ் அட்டவணைகள், செட்களுடன் பணிபுரிதல். நாங்கள் redis-benchmark ஐ அறிமுகப்படுத்தி, 80 பைப்லைனிங் முறையில் வினாடிக்கு ~1k செயல்பாடுகளைப் பெற்றோம்.

உயர் செயல்திறனுக்காக, நாங்கள் ரெடிஸை மிகவும் நேர்த்தியாக டியூன் செய்தோம்:

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

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

நிலையான NodeJS ஐப் பயன்படுத்தும் போது, Redis நூலகங்கள் ஒரு வினாடிக்கு 18k பரிவர்த்தனைகளின் செயல்திறனை அடைந்தன. வேகம் 9 முறை குறைந்தது.

சாத்தியக்கூறுகள் 5 மடங்கு அதிகமாக இருப்பதை அளவுகோல் காட்டியதால், நாங்கள் மேம்படுத்தத் தொடங்கினோம். நாங்கள் லைப்ரரியை ioredis ஆக மாற்றி, வினாடிக்கு 25k செயல்திறனைப் பெற்றோம். `hset` கட்டளையைப் பயன்படுத்தி பரிவர்த்தனைகளை ஒவ்வொன்றாகச் சேர்த்துள்ளோம். எனவே நாங்கள் ரெடிஸில் நிறைய வினவல்களை உருவாக்கிக் கொண்டிருந்தோம். பரிவர்த்தனைகளை தொகுதிகளாக இணைத்து, அவற்றை `hmset` என்ற ஒரே கட்டளையுடன் அனுப்பும் எண்ணம் எழுந்தது. இதன் விளைவாக வினாடிக்கு 32 ஆயிரம்.

பல காரணங்களுக்காக, நாங்கள் கீழே விவரிக்கும், நாங்கள் `Buffer` ஐப் பயன்படுத்தி தரவைக் கொண்டு வேலை செய்கிறோம், அதை நீங்கள் எழுதும் முன் உரையாக (`buffer.toString('hex')`) மாற்றினால், நீங்கள் கூடுதலாகப் பெறலாம். செயல்திறன். இதனால், வேகம் வினாடிக்கு 35 ஆயிரமாக அதிகரிக்கப்பட்டது. இந்த நேரத்தில், மேலும் மேம்படுத்துதலை இடைநிறுத்த முடிவு செய்தோம்.

நாம் பைனரி நெறிமுறைக்கு மாற வேண்டியிருந்தது, ஏனெனில்:

1. கணினி பெரும்பாலும் ஹாஷ்கள், கையொப்பங்கள் போன்றவற்றைக் கணக்கிடுகிறது, இதற்கு `பஃபரில் தரவு தேவைப்படுகிறது.

2. சேவைகளுக்கு இடையே அனுப்பப்படும் போது, பைனரி தரவு உரையை விட குறைவாக இருக்கும். எடுத்துக்காட்டாக, 1 மில்லியன் பரிவர்த்தனைகளுடன் ஒரு தொகுதியை அனுப்பும்போது, உரையில் உள்ள தரவு 300 மெகாபைட்டுகளுக்கு மேல் எடுக்கலாம்.

3. தரவை தொடர்ந்து மாற்றுவது செயல்திறனை பாதிக்கிறது.

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

இதன் விளைவாக, பின்வரும் தரவு கட்டமைப்புகளைப் பெற்றோம்:

- பரிவர்த்தனை

  ```json
  {
    prevHash: BD.types.buffer(20),
    prevBlock: BD.types.uint24le,
    tokenId: BD.types.string(null),
    type: BD.types.uint8,
    newOwner: BD.types.buffer(20),
    dataLength: BD.types.uint24le,
    data: BD.types.buffer(({current}) => current.dataLength),
    signature: BD.types.buffer(65),
    hash: BD.types.buffer(32),
    blockNumber: BD.types.uint24le,
    timestamp: BD.types.uint48le,
  }
  ```

- டோக்கன்

  ```json
  {
    id: BD.types.string(null),
    owner: BD.types.buffer(20),
    block: BD.types.uint24le,
    amount: BD.types.string(null),
  }
  ```

- தொகுதி

  ```json
  {
    number: BD.types.uint24le,
    merkleRootHash: BD.types.buffer(32),
    signature: BD.types.buffer(65),
    countTx: BD.types.uint24le,
    transactions: BD.types.array(Transaction.Protocol, ({current}) => current.countTx),
    timestamp: BD.types.uint48le,
  }
  ```

வழக்கமான கட்டளைகளான `BD.encode(block, Protocol).slice();` மற்றும் `BD.decode(buffer, Protocol)` மூலம், ரெடிஸில் சேமிப்பதற்கு அல்லது மற்றொரு முனைக்கு அனுப்புவதற்கும், மீட்டெடுப்பதற்கும் தரவை `Buffer` ஆக மாற்றுவோம். தரவு திரும்ப.

சேவைகளுக்கு இடையே தரவை மாற்றுவதற்கான 2 பைனரி நெறிமுறைகளும் எங்களிடம் உள்ளன:

— யூனிக்ஸ் சாக்கெட் வழியாக பிளாஸ்மா நோடுடன் தொடர்பு கொள்வதற்கான நெறிமுறை

  ```json
  {
    type: BD.types.uint8,
    messageId: BD.types.uint24le,
    error: BD.types.uint8,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

எங்கே:

`வகை` - செய்ய வேண்டிய செயல், எடுத்துக்காட்டாக, 1 — sendTransaction, 2 — getTransaction;
`பேலோடு` - பொருத்தமான செயல்பாட்டிற்கு அனுப்ப வேண்டிய தரவு;
`செய்தி ஐடி` - செய்தி ஐடி, இதனால் பதிலை அடையாளம் காண முடியும்.

- முனைகளுக்கு இடையிலான தொடர்புக்கான நெறிமுறை

  ```json
  {
    code: BD.types.uint8,
    versionProtocol: BD.types.uint24le,
    seq: BD.types.uint8,
    countChunk: BD.types.uint24le,
    chunkNumber: BD.types.uint24le,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

எங்கே:

`குறியீடு` — செய்திக் குறியீடு, எடுத்துக்காட்டாக 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
`பதிப்பு நெறிமுறை` - நெறிமுறை பதிப்பு, நெட்வொர்க்கில் வெவ்வேறு பதிப்புகளைக் கொண்ட முனைகளை உயர்த்தலாம் மற்றும் அவை வித்தியாசமாக வேலை செய்யலாம்;
`seq` - செய்தி அடையாளங்காட்டி;
`countChunk` и `சங்க் எண்` பெரிய செய்திகளைப் பிரிப்பதற்கு அவசியம்;
`நீளம்` и `பேலோடு` நீளம் மற்றும் தரவு தன்னை.

நாங்கள் தரவை முன்கூட்டியே தட்டச்சு செய்ததால், இறுதி அமைப்பு Ethereum இன் `rlp` நூலகத்தை விட மிக வேகமாக உள்ளது. துரதிர்ஷ்டவசமாக, எதிர்காலத்தில் நாங்கள் செய்ய திட்டமிட்டுள்ள ஸ்மார்ட் ஒப்பந்தத்தை இறுதி செய்ய வேண்டியது அவசியம் என்பதால், அதை எங்களால் இன்னும் மறுக்க முடியவில்லை.

நாம் வேகத்தை அடைய முடிந்தால் 35 000 ஒரு வினாடிக்கு பரிவர்த்தனைகள், நாம் அவற்றை உகந்த நேரத்தில் செயல்படுத்த வேண்டும். தோராயமான தொகுதி உருவாக்க நேரம் 30 வினாடிகள் எடுக்கும் என்பதால், நாம் தொகுதியில் சேர்க்க வேண்டும் 1 000 000 பரிவர்த்தனைகள், அதாவது மேலும் அனுப்புதல் 100 MB தரவு.

ஆரம்பத்தில், முனைகளுக்கு இடையே தொடர்புகொள்வதற்கு `ethereumjs-devp2p` நூலகத்தைப் பயன்படுத்தினோம், ஆனால் அதனால் அதிக தரவைக் கையாள முடியவில்லை. இதன் விளைவாக, நாங்கள் `ws` நூலகத்தைப் பயன்படுத்தினோம் மற்றும் வெப்சாக்கெட் வழியாக பைனரி தரவை அனுப்புவதை உள்ளமைத்தோம். நிச்சயமாக, பெரிய தரவு பாக்கெட்டுகளை அனுப்பும் போது நாங்கள் சிக்கல்களை எதிர்கொண்டோம், ஆனால் அவற்றை துண்டுகளாகப் பிரித்தோம், இப்போது இந்த சிக்கல்கள் நீங்கியுள்ளன.

மேலும் ஒரு மெர்க்கல் மரத்தை உருவாக்கி ஹாஷைக் கணக்கிடுகிறது 1 000 000 பரிவர்த்தனைகள் பற்றி தேவைப்படுகிறது 10 தொடர்ச்சியான கணக்கீடு விநாடிகள். இந்த நேரத்தில், அனைத்து முனைகளுடனான இணைப்பு உடைக்க நிர்வகிக்கிறது. இந்த கணக்கீட்டை ஒரு தனி நூலுக்கு நகர்த்த முடிவு செய்யப்பட்டது.

முடிவுகளை:

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

பொருள் சார்ந்த நிரலாக்கத்திற்குப் பதிலாக செயல்பாட்டு நிரலாக்கத்தைப் பயன்படுத்துவது உற்பத்தித்திறனை மேம்படுத்துகிறது.
ஒரு உற்பத்தி NodeJS அமைப்பிற்கான சேவை கட்டமைப்பை விட மோனோலித் மோசமாக உள்ளது.
கனமான கணக்கீட்டிற்கு `worker_threads` ஐப் பயன்படுத்துவது கணினியின் வினைத்திறனை மேம்படுத்துகிறது, குறிப்பாக i/o செயல்பாடுகளைக் கையாளும் போது.
unix சாக்கெட் http கோரிக்கைகளை விட நிலையானது மற்றும் வேகமானது.
நீங்கள் நெட்வொர்க்கில் பெரிய தரவை விரைவாக மாற்ற வேண்டும் என்றால், வெப்சாக்கெட்டுகளைப் பயன்படுத்தி பைனரி தரவை அனுப்புவது நல்லது, அவை வரவில்லை என்றால் அனுப்பப்படும், பின்னர் ஒரு செய்தியாக இணைக்கப்படும்.

பார்வையிட உங்களை அழைக்கிறோம் மகிழ்ச்சியா திட்டம்: https://github.com/opporty-com/Plasma-Cash/tree/new-version

கட்டுரை இணைந்து எழுதியது அலெக்சாண்டர் நசிவன், மூத்த டெவலப்பர் Clever Solution Inc.

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

பொது சோதனை: Ethereum இல் தனியுரிமை மற்றும் அளவிடுதல் ஒரு தீர்வு