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

કમનસીબે, બ્લોકચેનની પોતાની વિશિષ્ટ વિશેષતાઓ અને લાભો હોવા છતાં, તેના પર ચાલતી મોટાભાગની એપ્લિકેશનો તેમના કેન્દ્રિય સ્પર્ધકો કરતાં વધુ ખર્ચાળ, ધીમી અને ઓછી સાહજિક હોય છે.

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

એક સરળ ફકરામાં, ડીએપી ડેવલપર સ્કેલેબિલિટી સમસ્યાઓ અને સમસ્યાઓના વૈકલ્પિક ઉકેલોની ઊંડી ચર્ચા છોડી શકે છે. આ ઘણીવાર બિનકાર્યક્ષમ આર્કિટેક્ચર તરફ દોરી જાય છે જ્યાં બ્લોકચેન પર ચાલતા સ્માર્ટ કોન્ટ્રાક્ટ એપ્લિકેશનના બેકએન્ડ અને કોર તરીકે સેવા આપે છે.

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

ચાલો સૌપ્રથમ વધુ પરંપરાગત અભિગમ જોઈએ, જે બ્લોકચેનનો ઉપયોગ એપ્લિકેશન યુઝર્સ વચ્ચે સીધો મધ્યસ્થી તરીકે કરે છે, અને જે ખાસ કરીને સારી રીતે માપતો નથી.

અભિગમ #1: બેકએન્ડ તરીકે બ્લોકચેન

વસ્તુઓ સ્પષ્ટ કરવા માટે, ચાલો એક ઉદાહરણ તરીકે હોટેલ ઉદ્યોગ લઈએ. આ એક વિશાળ ઉદ્યોગ છે જેમાં મધ્યસ્થીઓ જેમ કે Booking.com, તેઓ મોટી ફી લે છે મહેમાનો અને હોટલને જોડવા માટે.

કોઈપણ પરિસ્થિતિમાં જ્યાં અમે આ અભિગમનો ઉપયોગ કરીને આવા મધ્યસ્થીને હરાવવા માંગીએ છીએ, અમે ઇથેરિયમ જેવા બ્લોકચેન પર સ્માર્ટ કોન્ટ્રાક્ટનો ઉપયોગ કરીને તેના વ્યવસાયિક તર્કની નકલ કરવાનો પ્રયાસ કરીશું.

"વર્લ્ડ કોમ્પ્યુટર" પર ચાલતા ઓપન સોર્સ સ્માર્ટ કોન્ટ્રાક્ટ્સ વચ્ચે તૃતીય પક્ષ વિના વેપારીઓને ગ્રાહકો સાથે જોડી શકે છે, આખરે મધ્યસ્થી દ્વારા વસૂલવામાં આવતી ફી અને કમિશનમાં ઘટાડો થાય છે.

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

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

આ અભિગમ સાથે માપનીયતા સમસ્યાની બે બાજુઓ છે. પ્રથમ, સેકન્ડ દીઠ વ્યવહારોની મહત્તમ સંખ્યા. બીજું, બ્લોકચેન પર સ્ટોર કરી શકાય તેટલો ડેટા.

ચાલો થોડી રફ ગણતરીઓ કરીએ. Booking.com કહે છે કે તેમની પાસે લગભગ 2 મિલિયન હોટેલ્સ નોંધાયેલી છે. ચાલો કહીએ કે સરેરાશ હોટલમાં 10 રૂમ હોય છે અને દરેક એક વર્ષમાં માત્ર 20 વખત બુક થાય છે - જે અમને પ્રતિ સેકન્ડ સરેરાશ 13 બુકિંગ આપે છે.

આ સંખ્યાને પરિપ્રેક્ષ્યમાં મૂકવા માટે, એ નોંધવું યોગ્ય છે કે Ethereum પ્રતિ સેકન્ડમાં આશરે 15 વ્યવહારો પર પ્રક્રિયા કરી શકે છે.

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

અહીં કદની સમસ્યાઓ પણ છે - ઇથેરિયમ બ્લોકચેનનું વજન તાજેતરમાં 2TB માર્કને પાર કરી ગયું છે. જો આ અભિગમ સાથેની એપ્લિકેશનો ખરેખર લોકપ્રિય બની જાય, તો Ethereum નેટવર્ક અત્યંત અસ્થિર બની જશે.

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

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

ઉદાહરણ તરીકે: દરેક હોટલનો ડેટા વિશ્વભરના સેંકડો મશીનોમાં વિતરિત કરવાનો અને તેને ત્યાં કાયમી ધોરણે સંગ્રહિત કરવાનો શું ફાયદો છે? શું તે ખરેખર મહત્વનું છે કે રૂમના દરો અને ઉપલબ્ધતા પરનો ઐતિહાસિક ડેટા હંમેશા બ્લોકચેનમાં સમાવવામાં આવે છે? કદાચ ના.

જો આપણે આવા પ્રશ્નો પૂછવાનું શરૂ કરીએ, તો અમે જોવાનું શરૂ કરીશું કે અમને અમારા તમામ કાર્યો માટે તમામ ખર્ચાળ બ્લોકચેન સુવિધાઓની જરૂર નથી. તો, વૈકલ્પિક શું છે?

અભિગમ #2: બ્લોકસ્ટેક પ્રેરિત આર્કિટેક્ચર

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

ડાબે: પ્રથમ અભિગમ, જેમાં વપરાશકર્તાઓ બ્લોકચેન દ્વારા ક્રિયાપ્રતિક્રિયા કરે છે. જમણે: વપરાશકર્તાઓ એકબીજા સાથે સીધો સંપર્ક કરે છે, અને બ્લોકચેનનો ઉપયોગ ફક્ત ઓળખ અને તેના જેવા માટે થાય છે.

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

શા માટે અમે મહેમાનો અને હોટલોને બ્લોકચેન દ્વારા સીધો સંપર્ક કરવાની મંજૂરી આપતા નથી. હોટેલ્સ તેમની કિંમતો, રૂમની ઉપલબ્ધતા અને કોઈપણ અન્ય માહિતીને એવી જગ્યાએ સંગ્રહિત કરી શકે છે જ્યાં તે દરેક માટે સુલભ હશે - ઉદાહરણ તરીકે, IPFS, Amazon S3 અથવા તો તેમનું પોતાનું સ્થાનિક સર્વર. બ્લોકસ્ટેકની વિકેન્દ્રિત સ્ટોરેજ સિસ્ટમને આ બરાબર કહેવાય છે ગૈયા. તે વપરાશકર્તાઓને તેઓનો ડેટા ક્યાં સંગ્રહિત કરવા માંગે છે તે પસંદ કરવાની મંજૂરી આપે છે અને કહેવાતા અભિગમ દ્વારા કોણ તેને ઍક્સેસ કરી શકે છે તે નિયંત્રિત કરે છે મલ્ટિ-યુઝર સ્ટોરેજ.

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

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

સિસ્ટમના સરળ સંસ્કરણમાં, મહેમાનો હોટલ શોધવા અને તેમના રૂમ વિશે માહિતી મેળવવા માટે બ્લોકસ્ટૅક પીઅર-ટુ-પીઅર નેટવર્કનો ઉપયોગ કરશે. અને તમે મેળવેલા તમામ ડેટાની પ્રામાણિકતા અને અખંડિતતા સાર્વજનિક કી અને હેશનો ઉપયોગ કરીને ચકાસી શકાય છે. વર્ચ્યુઅલ સર્કિટ બ્લોકસ્ટેક.

આ આર્કિટેક્ચર પ્રથમ અભિગમ કરતાં વધુ જટિલ છે અને વધુ વ્યાપક ઈન્ફ્રાસ્ટ્રક્ચરની જરૂર છે. વાસ્તવમાં, આ તે છે જ્યાં બ્લોકસ્ટેક આવે છે, આવી વિકેન્દ્રિત સિસ્ટમ બનાવવા માટે તમામ જરૂરી ઘટકો પ્રદાન કરે છે.

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

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

નિષ્કર્ષ

બ્લોકસ્ટેક પર ચાલતી એપ્લિકેશનો પરંપરાગત બ્લોકચેન એપ્લિકેશનો કરતાં ઘણી સારી રીતે સ્કેલ કરી શકે છે, પરંતુ તે તેની પોતાની સમસ્યાઓ અને અનુત્તરિત પ્રશ્નો સાથેનો એક નાનો અભિગમ છે.

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

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

લાખો વપરાશકર્તાઓની સંભવિતતા સાથે વૈશ્વિક બજારોને લક્ષ્યાંકિત કરતી એપ્લિકેશનો સફળ થવા માટે ખૂબ જ સારી રીતે સ્કેલ કરવી આવશ્યક છે. નજીકના ભવિષ્યમાં માપનીયતાના આ સ્તરને હાંસલ કરવા માટે ફક્ત બ્લોકચેન પર આધાર રાખવો એ એક ભૂલ છે. Booking.com જેવા મોટા કેન્દ્રિય બજારના ખેલાડીઓ સાથે સ્પર્ધા કરવામાં સક્ષમ થવા માટે, વિકેન્દ્રિત એપ્લિકેશન વિકાસકર્તાઓએ તેમની એપ્લિકેશન ડિઝાઇન કરવા માટે વૈકલ્પિક અભિગમો પર વિચાર કરવો જોઈએ, જેમ કે બ્લોકસ્ટેક દ્વારા ઓફર કરાયેલ.

સોર્સ: www.habr.com