જાહેર પરીક્ષણ: Ethereum પર ગોપનીયતા અને માપનીયતા માટેનો ઉકેલ

બ્લોકચેન એક નવીન તકનીક છે જે માનવ જીવનના ઘણા ક્ષેત્રોને સુધારવાનું વચન આપે છે. તે વાસ્તવિક પ્રક્રિયાઓ અને ઉત્પાદનોને ડિજિટલ સ્પેસમાં સ્થાનાંતરિત કરે છે, નાણાકીય વ્યવહારોની ઝડપ અને વિશ્વસનીયતા સુનિશ્ચિત કરે છે, તેમની કિંમત ઘટાડે છે અને તમને વિકેન્દ્રિત નેટવર્ક્સમાં સ્માર્ટ કોન્ટ્રાક્ટનો ઉપયોગ કરીને આધુનિક DAPP એપ્લિકેશન બનાવવાની પણ મંજૂરી આપે છે.

બ્લોકચેનના ઘણા ફાયદા અને વૈવિધ્યસભર એપ્લિકેશનોને જોતાં, તે આશ્ચર્યજનક લાગે છે કે આ આશાસ્પદ ટેક્નોલોજી હજુ સુધી દરેક ઉદ્યોગમાં પ્રવેશ કરી શકી નથી. સમસ્યા એ છે કે આધુનિક વિકેન્દ્રિત બ્લોકચેન્સમાં માપનીયતાનો અભાવ છે. Ethereum પ્રતિ સેકન્ડ લગભગ 20 વ્યવહારો પર પ્રક્રિયા કરે છે, જે આજના ગતિશીલ વ્યવસાયોની જરૂરિયાતોને પહોંચી વળવા માટે પૂરતું નથી. તે જ સમયે, બ્લોકચેન ટેક્નોલોજીનો ઉપયોગ કરતી કંપનીઓ હેકિંગ અને નેટવર્ક નિષ્ફળતાઓથી તેના ઉચ્ચ સ્તરના રક્ષણને કારણે ઇથેરિયમને છોડી દેવા માટે અચકાય છે.

બ્લોકચેનમાં વિકેન્દ્રીકરણ, સુરક્ષા અને માપનીયતા સુનિશ્ચિત કરવા માટે, આ રીતે સ્કેલબિલિટી ટ્રિલેમ્મા, વિકાસ ટીમ તક પ્લાઝમા કેશ બનાવ્યું, જે એક સ્માર્ટ કોન્ટ્રાક્ટ અને Node.js પર આધારિત ખાનગી નેટવર્ક ધરાવતી પેટાકંપની સાંકળ ધરાવે છે, જે સમયાંતરે તેની સ્થિતિને રૂટ ચેઇન (ઇથેરિયમ) પર સ્થાનાંતરિત કરે છે.

પ્લાઝ્મા કેશમાં મુખ્ય પ્રક્રિયાઓ

1. વપરાશકર્તા સ્માર્ટ કોન્ટ્રાક્ટ ફંક્શનને 'ડિપોઝિટ' કહે છે, તેમાં ETH ની રકમ પસાર કરે છે જે તે પ્લાઝમા કેશ ટોકનમાં જમા કરાવવા માંગે છે. સ્માર્ટ કોન્ટ્રાક્ટ ફંક્શન ટોકન બનાવે છે અને તેના વિશે એક ઇવેન્ટ જનરેટ કરે છે.

2. સ્માર્ટ કોન્ટ્રાક્ટ ઇવેન્ટ્સમાં સબ્સ્ક્રાઇબ કરેલ પ્લાઝમા કેશ નોડ્સ ડિપોઝિટ બનાવવા વિશેની ઇવેન્ટ મેળવે છે અને પૂલમાં ટોકન બનાવવા વિશેનો વ્યવહાર ઉમેરે છે.

3. સમયાંતરે, ખાસ પ્લાઝ્મા કેશ નોડ્સ પૂલ (1 મિલિયન સુધી) માંથી તમામ વ્યવહારો લે છે અને તેમાંથી એક બ્લોક બનાવે છે, મર્કલ વૃક્ષની ગણતરી કરે છે અને તે મુજબ, હેશ. આ બ્લોક ચકાસણી માટે અન્ય નોડ પર મોકલવામાં આવે છે. નોડ્સ તપાસે છે કે શું મર્કલ હેશ માન્ય છે અને વ્યવહારો માન્ય છે કે કેમ (ઉદાહરણ તરીકે, ટોકન મોકલનાર તેના માલિક છે કે નહીં). બ્લોકની ચકાસણી કર્યા પછી, નોડ સ્માર્ટ કોન્ટ્રાક્ટના `સબમિટબ્લોક` ફંક્શનને કૉલ કરે છે, જે બ્લોક નંબર અને મર્કલ હેશને એજ ચેઇનમાં સાચવે છે. સ્માર્ટ કોન્ટ્રાક્ટ એક ઇવેન્ટ જનરેટ કરે છે જે બ્લોકના સફળ ઉમેરોને દર્શાવે છે. વ્યવહારો પૂલમાંથી દૂર કરવામાં આવે છે.

4. નોડ્સ કે જે બ્લોક સબમિશન ઇવેન્ટ મેળવે છે તે વ્યવહારોને લાગુ કરવાનું શરૂ કરે છે જે બ્લોકમાં ઉમેરવામાં આવ્યા હતા.

5. અમુક સમયે, ટોકનના માલિક (અથવા બિન-માલિક) તેને પ્લાઝમા કેશમાંથી પાછી ખેંચવા માંગે છે. આ કરવા માટે, તે `startExit` ફંક્શનને કૉલ કરે છે, તેમાં ટોકન પરના છેલ્લા 2 વ્યવહારો વિશેની માહિતી પસાર કરે છે, જે પુષ્ટિ કરે છે કે તે ટોકનનો માલિક છે. સ્માર્ટ કોન્ટ્રાક્ટ, મર્કલ હેશનો ઉપયોગ કરીને, બ્લોક્સમાં વ્યવહારોની હાજરી તપાસે છે અને ઉપાડ માટે ટોકન મોકલે છે, જે બે અઠવાડિયામાં થશે.

6. જો ટોકન ઉપાડની કામગીરી ઉલ્લંઘન સાથે થઈ હોય (ટોકન ઉપાડની પ્રક્રિયા શરૂ થયા પછી ખર્ચવામાં આવી હતી અથવા ટોકન ઉપાડ પહેલા કોઈ અન્ય વ્યક્તિનું હતું), તો ટોકનનો માલિક બે અઠવાડિયાની અંદર ઉપાડનો ખંડન કરી શકે છે.

ગોપનીયતા બે રીતે પ્રાપ્ત થાય છે

1. રુટ ચેઇન ચાઇલ્ડ ચેઇનમાં જનરેટ અને ફોરવર્ડ કરવામાં આવતા વ્યવહારો વિશે કશું જ જાણતી નથી. પ્લાઝમા કેશમાંથી ETH કોણે જમા કરાવ્યું અને ઉપાડ્યું તે અંગેની માહિતી સાર્વજનિક રહે છે.

2. ચાઇલ્ડ ચેઇન zk-SNARK નો ઉપયોગ કરીને અનામી વ્યવહારોને મંજૂરી આપે છે.

ટેકનોલોજી સ્ટેક

• નોડજેએસ
• Redis
• ઇથેરિયમ
• માટી

પરીક્ષણ

પ્લાઝ્મા કેશ વિકસાવતી વખતે, અમે સિસ્ટમની ગતિનું પરીક્ષણ કર્યું અને નીચેના પરિણામો પ્રાપ્ત કર્યા:

• પ્રતિ સેકન્ડ 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 રેમ
રોપસ્ટેન ટેસ્ટનેટ 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 માન્ય છે અને સ્માર્ટ કોન્ટ્રાક્ટના `સબમિટબ્લોક` ફંક્શનને મર્કલ હેશ અને બ્લોક નંબર સાથે બોલાવવામાં આવે છે.
02:10 — ડેમો સ્ક્રિપ્ટે કામ પૂરું કર્યું, જેણે 1 સેકન્ડમાં 32 મિલિયન વ્યવહારો મોકલ્યા
02:33 - નોડ્સ એ માહિતી મેળવવાનું શરૂ કર્યું કે બ્લોક #8 રૂટ ચેઇનમાં ઉમેરવામાં આવ્યો છે, અને 240k વ્યવહારો કરવા લાગ્યા છે.
02:40 - 240k વ્યવહારો પૂલમાંથી દૂર કરવામાં આવ્યા હતા, જે પહેલાથી બ્લોક #8 માં છે
02:56 — સબમિટ નોડે પૂલમાંથી બાકીના 760k વ્યવહારો લીધા અને મર્કલ હેશ અને સાઈનિંગ બ્લોક #9ની ગણતરી કરવાનું શરૂ કર્યું.
03:20 - તમામ નોડ્સમાં 1 મિલિયન 240k વ્યવહારો અને ટોકન્સ છે
03:35 — બ્લોક #9 સહી થયેલ છે અને અન્ય નોડ્સને માન્યતા માટે મોકલવામાં આવે છે
03:41 - નેટવર્ક એરર આવી
04:40 — બ્લોક #9 માન્યતાની રાહ જોવાનો સમય સમાપ્ત થઈ ગયો છે
04:54 — સબમિટ નોડે પૂલમાંથી બાકીના 760k વ્યવહારો લીધા અને મર્કલ હેશ અને સાઈનિંગ બ્લોક #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 માં ઉમેરવામાં આવેલા 10k વ્યવહારો માટે પૂલ સાફ થઈ ગયો છે
02:15 — સબમિટ નોડે પૂલમાંથી 350k વ્યવહારો લીધા અને બ્લોક નંબર 11 બનાવ્યો
02:34 — બ્લોક #11 સહી થયેલ છે અને માન્યતા માટે અન્ય નોડ્સ પર મોકલવામાં આવે છે
02:51 — બ્લોક #11 માન્ય છે અને રૂટ ચેઇન પર મોકલવામાં આવે છે
02:55 — છેલ્લા નોડે બ્લોક #10 થી વ્યવહારો પૂર્ણ કર્યા
10:59 — બ્લોક #9 સબમિશન સાથેનો વ્યવહાર રૂટ ચેઇનમાં ઘણો લાંબો સમય લેતો હતો, પરંતુ તે પૂર્ણ થયું હતું અને તમામ નોડ્સે તેના વિશે માહિતી મેળવી હતી અને 350k વ્યવહારો કરવાનું શરૂ કર્યું હતું.
11:05 - બ્લોક #320 માં ઉમેરવામાં આવેલા 11k વ્યવહારો માટે પૂલ સાફ થઈ ગયો છે
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 એ પૂલમાંથી 330k વ્યવહારો લીધા અને બ્લોક #85 (f21) બનાવે છે. અમે એ પણ જોઈએ છીએ કે 350 સેકન્ડમાં 10k વ્યવહારો પૂલમાં ઉમેરવામાં આવે છે
01:53 — 1 મિલિયન વ્યવહારો બનાવવામાં આવ્યા અને નોડ #1 સબમિટ કરવા માટે મોકલવાનું શરૂ થયું
01:50 — સબમિટ નોડ #3 એ પૂલમાંથી 330k વ્યવહારો લીધા અને બ્લોક #85 (f21) બનાવે છે. અમે એ પણ જોઈએ છીએ કે 350 સેકન્ડમાં 10k વ્યવહારો પૂલમાં ઉમેરવામાં આવે છે
02:01 — સબમિટ નોડ #1 એ પૂલમાંથી 250k વ્યવહારો લીધા અને બ્લોક નંબર #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) ઉમેરવામાં આવી હતી અને 330k, 250k, 111855 વ્યવહારો લાગુ કરવાનું શરૂ કર્યું હતું.
03:49 - 330k, 250k, 111855 વ્યવહારો પર પૂલ સાફ કરવામાં આવ્યો હતો જે બ્લોક્સ #85 (f21), #86(65e), #87(256)માં ઉમેરવામાં આવ્યા હતા.
03:59 — સબમિટ નોડ #1 એ પૂલમાંથી 888145 વ્યવહારો કર્યા અને બ્લોક #88 (214) બનાવ્યા, સબમિટ નોડ #2 એ પૂલમાંથી 750k ટ્રાન્ઝેક્શન કર્યા અને બ્લોક #88 (50a), સબમિટ નોડ #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 પ્રદાન કરો. નોડજેએસ મૂળ રીતે સિંગલ-થ્રેડેડ હોવાથી, ભારે મર્કલ ટ્રી કેલ્ક્યુલેશન ફંક્શન એડ ટ્રાંઝેક્શન ફંક્શનને અવરોધિત કરે છે. અમે આ સમસ્યાને હલ કરવા માટે બે વિકલ્પો જોયા:

1. ઘણી નોડજેએસ પ્રક્રિયાઓ શરૂ કરો, જેમાંથી દરેક ચોક્કસ કાર્યો કરે છે.

2. worker_threads નો ઉપયોગ કરો અને કોડના ભાગના અમલને થ્રેડોમાં ખસેડો.

પરિણામે, અમે એક જ સમયે બંને વિકલ્પોનો ઉપયોગ કર્યો: અમે તાર્કિક રીતે એક નોડને 3 ભાગોમાં વિભાજિત કર્યો છે જે અલગથી કામ કરી શકે છે, પરંતુ તે જ સમયે સિંક્રનસ

1. સબમિશન નોડ, જે પૂલમાં વ્યવહારો સ્વીકારે છે અને બ્લોક્સ બનાવે છે.

2. એક માન્ય નોડ કે જે નોડ્સની માન્યતા તપાસે છે.

3. API નોડ - ડેટા ઍક્સેસ કરવા માટે API પ્રદાન કરે છે.

આ કિસ્સામાં, તમે cli નો ઉપયોગ કરીને યુનિક્સ સોકેટ દ્વારા દરેક નોડ સાથે કનેક્ટ કરી શકો છો.

અમે ભારે કામગીરી, જેમ કે મર્કલ વૃક્ષની ગણતરી, એક અલગ થ્રેડમાં ખસેડી.

આમ, અમે એકસાથે અને નિષ્ફળતા વિના તમામ પ્લાઝ્મા કેશ કાર્યોની સામાન્ય કામગીરી હાંસલ કરી છે.

એકવાર સિસ્ટમ કાર્યરત થઈ ગયા પછી, અમે ઝડપનું પરીક્ષણ કરવાનું શરૂ કર્યું અને, કમનસીબે, અસંતોષકારક પરિણામો પ્રાપ્ત થયા: પ્રતિ સેકન્ડ 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 અમારા માટે યોગ્ય નથી. મારે સંપૂર્ણ કાર્યાત્મક અભિગમ માટે બધું ફરીથી લખવું પડ્યું.

ડેટાબેઝમાં રેકોર્ડિંગ

શરૂઆતમાં, રેડિસને ડેટા સ્ટોરેજ માટે સૌથી વધુ ઉત્પાદક સોલ્યુશન્સ તરીકે પસંદ કરવામાં આવ્યું હતું જે અમારી જરૂરિયાતોને સંતોષે છે: કી-વેલ્યુ સ્ટોરેજ, હેશ કોષ્ટકો, સેટ સાથે કામ કરવું. અમે રેડિસ-બેન્ચમાર્ક લોન્ચ કર્યું અને 80 પાઇપલાઇનિંગ મોડમાં પ્રતિ સેકન્ડ ~1k ઑપરેશન્સ મેળવ્યા.

ઉચ્ચ પ્રદર્શન માટે, અમે રેડિસને વધુ બારીકાઈથી ટ્યુન કર્યું છે:

• યુનિક્સ સોકેટ કનેક્શન સ્થાપિત કરવામાં આવ્યું છે.
• અમે રાજ્યને ડિસ્ક પર સાચવવાનું અક્ષમ કર્યું છે (વિશ્વસનીયતા માટે, તમે પ્રતિકૃતિ સેટ કરી શકો છો અને અલગ રેડિસમાં ડિસ્ક પર સાચવી શકો છો).

રેડિસમાં, પૂલ એ હેશ ટેબલ છે કારણ કે આપણે એક ક્વેરીમાંથી તમામ વ્યવહારો પુનઃપ્રાપ્ત કરવા અને એક પછી એક વ્યવહારો કાઢી નાખવા માટે સક્ષમ બનવાની જરૂર છે. અમે નિયમિત સૂચિનો ઉપયોગ કરવાનો પ્રયાસ કર્યો, પરંતુ સંપૂર્ણ સૂચિને અનલોડ કરતી વખતે તે ધીમી છે.

પ્રમાણભૂત નોડજેએસનો ઉપયોગ કરતી વખતે, રેડિસ લાઇબ્રેરીઓએ પ્રતિ સેકન્ડ 18k વ્યવહારોનું પ્રદર્શન પ્રાપ્ત કર્યું. ઝડપ 9 વખત ઘટી.

બેન્ચમાર્કે અમને બતાવ્યું કે શક્યતાઓ સ્પષ્ટપણે 5 ગણી વધારે છે, અમે ઑપ્ટિમાઇઝ કરવાનું શરૂ કર્યું. અમે લાઇબ્રેરીને ioredis માં બદલી અને 25k પ્રતિ સેકન્ડનું પ્રદર્શન મેળવ્યું. અમે `hset` આદેશનો ઉપયોગ કરીને એક પછી એક વ્યવહારો ઉમેર્યા છે. તેથી અમે Redis માં ઘણી બધી ક્વેરી જનરેટ કરી રહ્યા હતા. વ્યવહારોને બેચમાં જોડવાનો અને તેમને એક આદેશ `hmset` સાથે મોકલવાનો વિચાર આવ્યો. પરિણામ 32k પ્રતિ સેકન્ડ છે.

ઘણા કારણોસર, જે અમે નીચે વર્ણવીશું, અમે `Buffer` નો ઉપયોગ કરીને ડેટા સાથે કામ કરીએ છીએ અને, જો તમે તેને લખતા પહેલા ટેક્સ્ટ (`buffer.toString('hex')`)માં રૂપાંતરિત કરો છો, તો તમે વધારાના મેળવી શકો છો. કામગીરી આમ, ઝડપ વધીને 35k પ્રતિ સેકન્ડ થઈ ગઈ. આ ક્ષણે, અમે વધુ ઑપ્ટિમાઇઝેશનને સ્થગિત કરવાનું નક્કી કર્યું છે.

અમારે બાઈનરી પ્રોટોકોલ પર સ્વિચ કરવું પડ્યું કારણ કે:

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)` સાથે અમે ડેટાને Redisમાં સાચવવા અથવા બીજા નોડ પર ફોરવર્ડ કરવા અને પુનઃપ્રાપ્ત કરવા માટે `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 — મોકલો વ્યવહાર, 2 — getTransaction;
• `પેલોડ` - ડેટા કે જે યોગ્ય કાર્યમાં પસાર કરવાની જરૂર છે;
• `messageId` - મેસેજ આઈડી જેથી પ્રતિભાવ ઓળખી શકાય.

- નોડ્સ વચ્ચે ક્રિયાપ્રતિક્રિયા માટે પ્રોટોકોલ

  ```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` - સંદેશ ઓળખકર્તા;
• `કાઉન્ટચંક` и `ચંકનંબર` મોટા સંદેશાઓને વિભાજિત કરવા માટે જરૂરી;
• `લંબાઈ` и `પેલોડ` લંબાઈ અને ડેટા પોતે.

અમે ડેટા પ્રી-ટાઈપ કર્યો હોવાથી, અંતિમ સિસ્ટમ Ethereum ની `rlp` લાઇબ્રેરી કરતાં ઘણી ઝડપી છે. કમનસીબે, અમે હજી સુધી તેનો ઇનકાર કરી શક્યા નથી, કારણ કે સ્માર્ટ કોન્ટ્રાક્ટને અંતિમ સ્વરૂપ આપવું જરૂરી છે, જે અમે ભવિષ્યમાં કરવાની યોજના બનાવીએ છીએ.

જો આપણે ઝડપ સુધી પહોંચવામાં સફળ થયા 35 000 પ્રતિ સેકન્ડ વ્યવહારો, અમે પણ શ્રેષ્ઠ સમય માં તેમને પ્રક્રિયા કરવાની જરૂર છે. અંદાજિત બ્લોક બનાવવાનો સમય 30 સેકન્ડ લેતો હોવાથી, અમારે બ્લોકમાં સમાવેશ કરવાની જરૂર છે 1 000 000 વ્યવહારો, જેનો અર્થ છે વધુ મોકલવું 100 MB ડેટા.

શરૂઆતમાં, અમે નોડ્સ વચ્ચે વાતચીત કરવા માટે `ethereumjs-devp2p` લાઇબ્રેરીનો ઉપયોગ કર્યો હતો, પરંતુ તે આટલો ડેટા હેન્ડલ કરી શકતો નથી. પરિણામે, અમે `ws` લાઇબ્રેરીનો ઉપયોગ કર્યો અને વેબસોકેટ દ્વારા બાઈનરી ડેટા મોકલવાનું ગોઠવ્યું. અલબત્ત, મોટા ડેટા પેકેટો મોકલતી વખતે પણ અમને સમસ્યાઓનો સામનો કરવો પડ્યો હતો, પરંતુ અમે તેમને ભાગોમાં વિભાજિત કર્યા અને હવે આ સમસ્યાઓ દૂર થઈ ગઈ છે.

મર્કલ વૃક્ષની રચના અને હેશની ગણતરી પણ 1 000 000 વ્યવહારો વિશે જરૂરી છે 10 સતત ગણતરીની સેકન્ડ. આ સમય દરમિયાન, તમામ ગાંઠો સાથેનું જોડાણ તૂટી જવાની વ્યવસ્થા કરે છે. આ ગણતરીને એક અલગ થ્રેડ પર ખસેડવાનું નક્કી કરવામાં આવ્યું હતું.

તારણો:

હકીકતમાં, અમારા તારણો નવા નથી, પરંતુ કેટલાક કારણોસર વિકાસ કરતી વખતે ઘણા નિષ્ણાતો તેમના વિશે ભૂલી જાય છે.

• ઑબ્જેક્ટ-ઓરિએન્ટેડ પ્રોગ્રામિંગને બદલે ફંક્શનલ પ્રોગ્રામિંગનો ઉપયોગ કરવાથી ઉત્પાદકતામાં સુધારો થાય છે.
• મોનોલિથ ઉત્પાદક નોડજેએસ સિસ્ટમ માટે સર્વિસ આર્કિટેક્ચર કરતાં વધુ ખરાબ છે.
• ભારે ગણતરી માટે `વર્કર_થ્રેડ્સ` નો ઉપયોગ કરવાથી સિસ્ટમની પ્રતિભાવશક્તિમાં સુધારો થાય છે, ખાસ કરીને જ્યારે i/o ઑપરેશન્સ સાથે કામ કરતી વખતે.
• યુનિક્સ સોકેટ HTTP વિનંતીઓ કરતાં વધુ સ્થિર અને ઝડપી છે.
• જો તમારે નેટવર્ક પર મોટા ડેટાને ઝડપથી સ્થાનાંતરિત કરવાની જરૂર હોય, તો વેબસોકેટ્સનો ઉપયોગ કરવો અને દ્વિસંગી ડેટા મોકલવો વધુ સારું છે, ટુકડાઓમાં વિભાજિત, જે ન આવે તો ફોરવર્ડ કરી શકાય છે, અને પછી એક સંદેશમાં જોડાઈ શકે છે.

અમે તમને મુલાકાત લેવા આમંત્રણ આપીએ છીએ GitHub પ્રોજેક્ટ: https://github.com/opporty-com/Plasma-Cash/tree/new-version

લેખ સહ દ્વારા લખવામાં આવ્યો હતો એલેક્ઝાન્ડર નાશિવન, વરિષ્ઠ વિકાસકર્તા હોંશિયાર ઉકેલ Inc.

સોર્સ: www.habr.com