TON: ટેલિગ્રામ ઓપન નેટવર્ક. ભાગ 2: બ્લોકચેન, શાર્ડિંગ

આ ટેક્સ્ટ લેખોની શ્રેણીનું ચાલુ છે જેમાં હું (સંભવતઃ) વિતરિત નેટવર્ક ટેલિગ્રામ ઓપન નેટવર્ક (TON) ની રચનાનું પરીક્ષણ કરું છું, જે આ વર્ષે રિલીઝ માટે તૈયાર કરવામાં આવી રહ્યું છે. IN અગાઉનો ભાગ મેં તેનું સૌથી મૂળભૂત સ્તર વર્ણવ્યું - જે રીતે ગાંઠો એકબીજા સાથે ક્રિયાપ્રતિક્રિયા કરે છે.

માત્ર કિસ્સામાં, હું તમને યાદ અપાવી દઉં કે આ નેટવર્કના વિકાસ સાથે મારે કોઈ લેવાદેવા નથી અને બધી સામગ્રી ખુલ્લા (અનવેધિત હોવા છતાં) સ્ત્રોતમાંથી એકત્રિત કરવામાં આવી હતી - દસ્તાવેજ (એક સાથ પણ છે પુસ્તિકા, સંક્ષિપ્તમાં મુખ્ય મુદ્દાઓની રૂપરેખા), જે ગયા વર્ષના અંતમાં દેખાયા હતા. આ દસ્તાવેજમાંની માહિતીની માત્રા, મારા મતે, તેની અધિકૃતતા સૂચવે છે, જો કે આની કોઈ સત્તાવાર પુષ્ટિ નથી.

આજે આપણે TON ના મુખ્ય ઘટક - બ્લોકચેનને જોઈશું.

મૂળભૂત ખ્યાલો

એકાઉન્ટ (એકાઉન્ટ). 256-બીટ નંબર દ્વારા ઓળખાયેલ ડેટાનો સમૂહ એકાઉન્ટ_આઈડી (મોટાભાગે આ એકાઉન્ટ માલિકની સાર્વજનિક કી હોય છે). બેઝ કેસમાં (નીચે જુઓ શૂન્ય વર્કચેન), આ ડેટા વપરાશકર્તાના સંતુલનનો સંદર્ભ આપે છે. "કબજો" ચોક્કસ એકાઉન્ટ_આઈડી કોઈપણ કરી શકે છે, પરંતુ તેની કિંમત અમુક નિયમો અનુસાર જ બદલી શકાય છે.

સ્માર્ટ કરાર (સ્માર્ટ-કોન્ટ્રાક્ટ). સારમાં, તે એકાઉન્ટનો એક વિશિષ્ટ કેસ છે, જે સ્માર્ટ કોન્ટ્રાક્ટ કોડ અને તેના ચલોના સંગ્રહ સાથે પૂરક છે. જો "વૉલેટ" ના કિસ્સામાં તમે પ્રમાણમાં સરળ અને પૂર્વનિર્ધારિત નિયમો અનુસાર તેમાંથી પૈસા જમા અને ઉપાડી શકો છો, તો પછી સ્માર્ટ કરારના કિસ્સામાં આ નિયમો તેના કોડના રૂપમાં લખવામાં આવે છે (ચોક્કસ ટ્યુરિંગ-સંપૂર્ણ પ્રોગ્રામિંગ ભાષા).

બ્લોકચેન રાજ્ય (બ્લોકચેનની સ્થિતિ). તમામ એકાઉન્ટ્સ/સ્માર્ટ કોન્ટ્રાક્ટની સ્થિતિનો સમૂહ (એક અમૂર્ત અર્થમાં, હેશ ટેબલ, જ્યાં કી એ એકાઉન્ટ આઇડેન્ટિફાયર છે અને મૂલ્યો એકાઉન્ટ્સમાં સંગ્રહિત ડેટા છે).

સંદેશ (સંદેશ). ઉપર મેં "ક્રેડિટ અને ડેબિટ મની" અભિવ્યક્તિનો ઉપયોગ કર્યો - આ સંદેશનું ચોક્કસ ઉદાહરણ છે ("ટ્રાન્સફર એન ગ્રામ ખાતામાંથી એકાઉન્ટ_1 એકાઉન્ટ માટે એકાઉન્ટ_2"). દેખીતી રીતે, ફક્ત નોડ જે એકાઉન્ટની ખાનગી કી ધરાવે છે તે જ આવો સંદેશ મોકલી શકે છે એકાઉન્ટ_1 - અને સહી સાથે આની પુષ્ટિ કરવા સક્ષમ. આવા સંદેશાઓને નિયમિત ખાતામાં પહોંચાડવાનું પરિણામ તેના સંતુલનમાં વધારો છે, અને સ્માર્ટ કરારનું પરિણામ તેના કોડનું અમલીકરણ છે (જે સંદેશની રસીદ પર પ્રક્રિયા કરશે). અલબત્ત, અન્ય સંદેશાઓ પણ શક્ય છે (નાણાકીય રકમનું સ્થાનાંતરણ નહીં, પરંતુ સ્માર્ટ કોન્ટ્રાક્ટ વચ્ચે મનસ્વી ડેટા).

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

TON માં બ્લોકચેન: તે શું છે અને શા માટે?

અગાઉના લેખમાં જણાવ્યા મુજબ, બ્લોકચેન એ ડેટા સ્ટ્રક્ચર છે, જેનાં તત્વો (બ્લોક) ને "ચેઈન" માં ઓર્ડર કરવામાં આવે છે, અને સાંકળના દરેક અનુગામી બ્લોકમાં પહેલાની એક હેશ હોય છે.. ટિપ્પણીઓએ પ્રશ્ન પૂછ્યો: જ્યારે અમારી પાસે પહેલેથી જ DHT - વિતરિત હેશ ટેબલ હોય ત્યારે અમને આવા ડેટા સ્ટ્રક્ચરની જરૂર કેમ છે? દેખીતી રીતે, કેટલાક ડેટા DHT માં સંગ્રહિત કરી શકાય છે, પરંતુ આ ફક્ત "સંવેદનશીલ" માહિતી માટે યોગ્ય નથી. ક્રિપ્ટોકરન્સી બેલેન્સ DHT માં સંગ્રહિત કરી શકાતું નથી - મુખ્યત્વે ચેકના અભાવને કારણે અખંડિતતા. વાસ્તવમાં, બ્લોકચેન સ્ટ્રક્ચરની સમગ્ર જટિલતા તેમાં સંગ્રહિત ડેટા સાથે દખલગીરીને રોકવા માટે વધે છે.

જો કે, TON માં બ્લોકચેન મોટાભાગની અન્ય વિતરિત સિસ્ટમો કરતાં પણ વધુ જટિલ લાગે છે - અને બે કારણોસર. પ્રથમ જરૂરિયાત ઘટાડવાની ઇચ્છા છે કાંટો. પરંપરાગત ક્રિપ્ટોકરન્સીમાં, તમામ પરિમાણો પ્રારંભિક તબક્કે સેટ કરવામાં આવે છે અને તેમને બદલવાનો કોઈપણ પ્રયાસ વાસ્તવમાં "વૈકલ્પિક ક્રિપ્ટોકરન્સી બ્રહ્માંડ"ના ઉદભવ તરફ દોરી જાય છે. બીજું કારણ કચડી નાખવા માટેનો આધાર છે (શાર્ડિંગ, શાર્ડિંગ) બ્લોકચેન. બ્લોકચેન એ એક માળખું છે જે સમય જતાં નાનું થઈ શકતું નથી; અને સામાન્ય રીતે નેટવર્કના સંચાલન માટે જવાબદાર દરેક નોડને તેને સંપૂર્ણપણે સંગ્રહિત કરવાની ફરજ પાડવામાં આવે છે. પરંપરાગત (કેન્દ્રિત) પ્રણાલીઓમાં, શાર્ડિંગનો ઉપયોગ આવી સમસ્યાઓ ઉકેલવા માટે થાય છે: ડેટાબેઝમાંના કેટલાક રેકોર્ડ્સ એક સર્વર પર સ્થિત છે, કેટલાક બીજા પર, વગેરે. ક્રિપ્ટોકરન્સીના કિસ્સામાં, આવી કાર્યક્ષમતા હજુ પણ ખૂબ જ દુર્લભ છે - ખાસ કરીને, એ હકીકતને કારણે કે જ્યાં તે મૂળ રૂપે આયોજિત ન હોય તેવી સિસ્ટમમાં શાર્ડિંગ ઉમેરવું મુશ્કેલ છે.

ઉપરોક્ત બંને સમસ્યાઓ ઉકેલવા માટે TON કેવી રીતે આયોજન કરે છે?

બ્લોકચેન સામગ્રી. વર્કચેન્સ.

સૌ પ્રથમ, ચાલો બ્લોકચેનમાં શું સંગ્રહિત કરવાની યોજના છે તે વિશે વાત કરીએ. એકાઉન્ટની સ્થિતિઓ (બેઝ કેસમાં "વૉલેટ્સ") અને સ્માર્ટ કોન્ટ્રાક્ટ્સ ત્યાં સંગ્રહિત કરવામાં આવશે (સરળતા માટે, અમે માનીશું કે આ એકાઉન્ટ્સ જેવું જ છે). સારમાં, આ એક નિયમિત હેશ ટેબલ હશે - તેમાંની ચાવીઓ ઓળખકર્તા હશે એકાઉન્ટ_આઈડી, અને મૂલ્યો ડેટા સ્ટ્રક્ચર્સ છે જેમાં આવી વસ્તુઓ શામેલ છે:

• સંતુલન;
• સ્માર્ટ કોન્ટ્રાક્ટ કોડ (ફક્ત સ્માર્ટ કોન્ટ્રાક્ટ માટે);
• સ્માર્ટ કોન્ટ્રાક્ટ ડેટા સ્ટોરેજ (માત્ર સ્માર્ટ કોન્ટ્રાક્ટ માટે);
• આંકડા
• (વૈકલ્પિક) એકાઉન્ટમાંથી ટ્રાન્સફર માટે સાર્વજનિક કી, ડિફૉલ્ટ account_id તરીકે;
• આઉટગોઇંગ સંદેશાઓની કતાર (અહીં તેઓ પ્રાપ્તકર્તાને ફોરવર્ડ કરવા માટે દાખલ કરવામાં આવ્યા છે);
• આ એકાઉન્ટ પર વિતરિત નવીનતમ સંદેશાઓની સૂચિ.

ઉપર સૂચવ્યા મુજબ, બ્લોક્સ પોતે વ્યવહારો ધરાવે છે - વિવિધ account_id એકાઉન્ટ્સ પર વિતરિત સંદેશાઓ. જો કે, account_id ઉપરાંત, સંદેશામાં 32-બીટ ફીલ્ડ પણ હોય છે workchain_id — કહેવાતા ઓળખકર્તા વર્કચેન (વર્કચેન, કાર્યરત બ્લોકચેન). આ તમને વિવિધ રૂપરેખાંકનો સાથે એકબીજાથી સ્વતંત્ર ઘણા બ્લોકચેન રાખવાની મંજૂરી આપે છે. આ કિસ્સામાં, વર્કચેન_આઈડી = 0 એક વિશિષ્ટ કેસ માનવામાં આવે છે, શૂન્ય વર્કચેન - તે તેમાં રહેલ બેલેન્સ છે જે TON (ગ્રામ) ક્રિપ્ટોકરન્સીને અનુરૂપ હશે. મોટે ભાગે, શરૂઆતમાં, અન્ય વર્કચેન્સ બિલકુલ અસ્તિત્વમાં રહેશે નહીં.

શાર્ડચેન્સ. અનંત શાર્ડિંગ પેરાડાઈમ.

પરંતુ બ્લોકચેનની સંખ્યામાં વૃદ્ધિ ત્યાં અટકતી નથી. ચાલો શાર્ડિંગ સાથે વ્યવહાર કરીએ. ચાલો કલ્પના કરીએ કે દરેક એકાઉન્ટ (account_id) ને તેનું પોતાનું બ્લોકચેન ફાળવવામાં આવ્યું છે - તેમાં તેના પર આવતા તમામ સંદેશાઓ છે - અને આવા તમામ બ્લોકચેનની સ્થિતિ અલગ નોડ્સ પર સંગ્રહિત છે.

અલબત્ત, આ ખૂબ જ નકામું છે: મોટે ભાગે, આમાંના દરેકમાં શાર્ડચેન્સ (શાર્ડચેન, શાર્ડ બ્લોકચેન) વ્યવહારો ખૂબ જ ભાગ્યે જ આવશે, અને ઘણા બધા શક્તિશાળી નોડ્સની જરૂર પડશે (આગળ જોતા, હું નોંધું છું કે અમે ફક્ત મોબાઇલ ફોન પરના ક્લાયન્ટ્સ વિશે જ વાત કરી રહ્યા નથી - પરંતુ ગંભીર સર્વર્સ વિશે).

તેથી, શાર્ડચેન્સ તેમના ઓળખકર્તાઓના દ્વિસંગી ઉપસર્ગો દ્વારા એકાઉન્ટ્સને જોડે છે: જો શાર્ડચેનનો ઉપસર્ગ 0110 હોય, તો તેમાં આ નંબરોથી શરૂ થતા તમામ account_idsના વ્યવહારો શામેલ હશે. આ shard_prefix 0 થી 60 બિટ્સ સુધીની લંબાઈ હોઈ શકે છે - અને મુખ્ય વસ્તુ એ છે કે તે ગતિશીલ રીતે બદલી શકે છે.

જલદી શાર્ડચેનમાંથી એકને ઘણા બધા વ્યવહારો પ્રાપ્ત થવાનું શરૂ થાય છે, તેના પર કામ કરતા ગાંઠો, પૂર્વનિર્ધારિત નિયમો અનુસાર, તેને બે બાળકોમાં "વિભાજિત કરો" - તેમના ઉપસર્ગ એક બીટ લાંબા હશે (અને તેમાંથી એક માટે આ બીટ હશે. 0 ની બરાબર, અને બીજા માટે - 1). દાખ્લા તરીકે, shard_prefix = 0110b માં વિભાજિત થશે 01100b અને 01101 બી. બદલામાં, જો બે "પડોશી" શાર્ડચેન પૂરતી સરળતા અનુભવવા લાગે છે (થોડા સમય માટે), તેઓ ફરીથી મર્જ થઈ જશે.

આમ, શાર્ડિંગ "નીચેથી ઉપર" કરવામાં આવે છે - અમે ધારીએ છીએ કે દરેક ખાતાની પોતાની શાર્ડ હોય છે, પરંતુ તે સમય માટે તેઓ ઉપસર્ગ દ્વારા "એકસાથે ગુંદર ધરાવતા" હોય છે. તેનો અર્થ આ છે અનંત શાર્ડિંગ પેરાડાઈમ (અનંત શાર્ડિંગ પેરાડાઈમ).

અલગથી, હું ભારપૂર્વક કહેવા માંગુ છું કે વર્કચેન્સ ફક્ત વર્ચ્યુઅલ રીતે અસ્તિત્વમાં છે - હકીકતમાં, workchain_id તે ચોક્કસ શાર્ડચેઈનના ઓળખકર્તાનો ભાગ છે. ઔપચારિક શબ્દોમાં, દરેક શાર્ડચેનને સંખ્યાઓની જોડી દ્વારા વ્યાખ્યાયિત કરવામાં આવે છે (workchain_id, shard_prefix).

ભૂલ સુધારણા. વર્ટિકલ બ્લોકચેન્સ.

પરંપરાગત રીતે, બ્લોકચેન પરના કોઈપણ વ્યવહારને "પથ્થર પર સેટ" ગણવામાં આવે છે. જો કે, TON ના કિસ્સામાં, "ઇતિહાસ ફરીથી લખવું" શક્ય છે - જો કોઈ વ્યક્તિ (કહેવાતા. માછીમાર ગાંઠ) સાબિત કરશે કે એક બ્લોક પર ખોટી રીતે સહી કરવામાં આવી હતી. આ કિસ્સામાં, અનુરૂપ શાર્ડચેનમાં એક ખાસ કરેક્શન બ્લોક ઉમેરવામાં આવે છે, જેમાં બ્લોકની હેશ પોતે જ સુધારાઈ રહી છે (અને શાર્ડચેનમાં છેલ્લો બ્લોક નહીં). શાર્ડચેનને આડી રીતે મૂકેલા બ્લોક્સની સાંકળ તરીકે વિચારીને, આપણે કહી શકીએ કે સુધારાત્મક બ્લોક ભૂલભરેલા બ્લોક સાથે જમણી બાજુએ નહીં, પરંતુ ઉપરથી જોડાયેલ છે - તેથી એવું માનવામાં આવે છે કે તે નાના "વર્ટિકલ બ્લોકચેન" નો ભાગ બની જાય છે. . આમ, આપણે કહી શકીએ કે શાર્ડચેન્સ છે દ્વિ-પરિમાણીય બ્લોકચેન.

જો, ભૂલભરેલા બ્લોક પછી, તેના દ્વારા કરાયેલા ફેરફારોને અનુગામી બ્લોક્સ દ્વારા સંદર્ભિત કરવામાં આવ્યા હતા (એટલે ​​​​કે, અમાન્ય લોકોના આધારે નવા વ્યવહારો કરવામાં આવ્યા હતા), સુધારાત્મક મુદ્દાઓ પણ આ બ્લોક્સમાં "ટોચ પર" ઉમેરવામાં આવે છે. જો બ્લોક્સ "અસરગ્રસ્ત" માહિતીને અસર કરતા નથી, તો આ "સુધારક તરંગો" તેમને લાગુ પડતા નથી. ઉદાહરણ તરીકે, ઉપરના ચિત્રમાં, ખાતા C ના બેલેન્સમાં વધારો કરતા પહેલા બ્લોકના વ્યવહારને ખોટા તરીકે ઓળખવામાં આવ્યો હતો - તેથી, ત્રીજા બ્લોકમાં આ ખાતાના બેલેન્સમાં ઘટાડો થતો વ્યવહાર પણ રદ થવો જોઈએ, અને સુધારાત્મક બ્લોક બ્લોકની ટોચ પર જ પ્રતિબદ્ધ હોવું જોઈએ.

એ નોંધવું જોઈએ કે જો કે સુધારાત્મક બ્લોક્સને મૂળ બ્લોકની "ઉપર" સ્થિત તરીકે દર્શાવવામાં આવ્યા છે, વાસ્તવમાં તે અનુરૂપ બ્લોકચેનના અંતમાં ઉમેરવામાં આવશે (જ્યાં તે કાલક્રમ મુજબ હોવા જોઈએ). દ્વિ-પરિમાણીય સ્થાન ફક્ત તે બતાવે છે કે બ્લોકચેનમાં તેઓ કયા બિંદુથી "લિંક" હશે (તેમાં સ્થિત મૂળ બ્લોકના હેશ દ્વારા).

"ભૂતકાળને બદલવાનો" નિર્ણય કેટલો સારો છે તે વિશે તમે અલગથી ફિલસૂફી કરી શકો છો. એવું લાગે છે કે જો આપણે શાર્ડચેનમાં ખોટા બ્લોક દેખાવાની શક્યતાને સ્વીકારીએ, તો પછી આપણે ભૂલભરેલા સુધારાત્મક બ્લોકના દેખાવની શક્યતાને ટાળી શકતા નથી. અહીં, જ્યાં સુધી હું કહી શકું છું, તફાવત એ નોડ્સની સંખ્યામાં છે કે જે નવા બ્લોક્સ પર સર્વસંમતિ સુધી પહોંચવા જોઈએ - દરેક શાર્ડચેન પર કામ કરતા લોકોની સંખ્યા પ્રમાણમાં ઓછી હશે."કાર્યકારી જૂથ» નોડ્સ (જે તેની રચના ઘણી વાર બદલે છે), અને સુધારાત્મક બ્લોક્સની રજૂઆત માટે દરેકની સંમતિની જરૂર પડશે વેલિડેટર નોડ્સ. હું હવે પછીના લેખમાં વેલિડેટર્સ, વર્કગ્રુપ્સ અને અન્ય નોડની ભૂમિકાઓ વિશે વધુ વાત કરીશ.

તે બધા પર શાસન કરવા માટે એક બ્લોકચેન

બ્લોકચેનના વિવિધ પ્રકારો વિશે ઉપર સૂચિબદ્ધ ઘણી બધી માહિતી છે, જે પોતે પણ ક્યાંક સંગ્રહિત હોવી જોઈએ. ખાસ કરીને, અમે નીચેની માહિતી વિશે વાત કરી રહ્યા છીએ:

• વર્કચેનની સંખ્યા અને ગોઠવણીઓ વિશે;
• શાર્ડચેઇન્સ અને તેમના ઉપસર્ગની સંખ્યા વિશે;
• કયા ગાંઠો હાલમાં શાર્ડચેઇન્સ માટે જવાબદાર છે તે વિશે;
• છેલ્લા બ્લોકની હેશ બધી શાર્ડચેનમાં ઉમેરવામાં આવી છે.

જેમ તમે અનુમાન લગાવ્યું હશે, આ બધી વસ્તુઓ અન્ય બ્લોકચેન સ્ટોરેજમાં રેકોર્ડ કરવામાં આવી છે - માસ્ટરચેન (માસ્ટરચેન, માસ્ટર બ્લોકચેન). તેના બ્લોક્સમાં તમામ શાર્ડચેઈન્સના બ્લોકમાંથી હેશની હાજરીને કારણે, તે સિસ્ટમને ખૂબ જ કનેક્ટેડ બનાવે છે. આનો અર્થ એ છે કે, અન્ય વસ્તુઓની સાથે, માસ્ટરચેનમાં નવા બ્લોકની જનરેશન શાર્ડચેનમાં બ્લોક્સની જનરેશન પછી તરત જ થશે - એવી અપેક્ષા રાખવામાં આવે છે કે શાર્ડચેનમાં બ્લોક્સ લગભગ દર 5 સેકન્ડમાં એક સાથે દેખાશે, અને આગામી બ્લોક માસ્ટરચેન - તે પછી એક સેકન્ડ.

પરંતુ આ બધા ટાઇટેનિક કાર્યના અમલીકરણ માટે કોણ જવાબદાર હશે - સંદેશા મોકલવા, સ્માર્ટ કોન્ટ્રાક્ટ ચલાવવા, શાર્ડચેન અને માસ્ટરચેનમાં બ્લોક્સ બનાવવા અને ભૂલો માટે બ્લોક્સ તપાસવા માટે પણ? શું ટેલિગ્રામ ક્લાયંટ ઇન્સ્ટોલ કરેલા લાખો વપરાશકર્તાઓના ફોન દ્વારા આ બધું ગુપ્ત રીતે કરવામાં આવશે? અથવા, કદાચ, દુરોવ ટીમ વિકેન્દ્રીકરણના વિચારોને છોડી દેશે અને તેમના સર્વરો તે જૂના જમાનાની રીતે કરશે?

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

સોર્સ: www.habr.com