# Web 3.0 არქიტექტურა

By [Nebo](https://paragraph.com/@nebo) · 2022-12-14

---

Web 3.0-ის, იგივე Dapp-ის (Decentralized Application) არქიტექტურა საკმაოდ განსხვავდება Web 2.0 აპლიკაციებისგან.

მაგალითად ავიღოთ Medium, პლატფორმა სადაც ახლა ვიმყოფებით. ეს არის მარტივი Blog-ის ტიპის საიტი, რომელიც მომხმარებლებს საშუალებას აძლევს წერონ საკუთარი ან იკითხონ სხვისი სტატიები.

რეალურად მარტივი Web 2.0 აპლიკაციის მიღმაც, საკმაოდ ბევრი რამ ხდება. ზედაპირულად განვიხილოთ Medium-ის არქიტექტურა.

1.  აუცილებლად უნდა არსებობდეს ადგილი (Database), სადაც ისეთი მონაცემები ინახება, როგორიც არის User-ები, Post-ები, Comment-ები, Like-ები და ასე შემდეგ.
    
2.  უნდა არსებობდეს ბიზნეს ლოგიკა (Back-End) დაწერილი ისეთ პროგრამულ ენებზე როგორიც არის: Python, Node.js, Java, C#… ბიზნეს ლოგიკა მოიცავს User-ის ავტორიზაცია/რეგისტრაციას, Post-ის განთავსებას და ასე შემდეგ.
    
3.  უნდა არსებობდეს ვიზუალი (Front-End) შექმნილი Js, HTML, CSS-ის დახმარებით. რაც თავის თავში მოიცავს თუ როგორ გამოიყურება საიტი და რა ხდება საიტზე განთავსებულ ელემენტზე დაჭერით.
    

ხოლო თუ ამ ყველაფერს შევკრავთ, მივიღებთ, რომ კლიენტი ახდენს ქმედებას Front-End-ში, Front-End ესაუბრება Back-End-ს, ხოლო Back-End ესაუბრება Database-ს. მთლიანი ეს კოდი განთავსებულია ერთ ცენტრალიზებულ Web Server-ზე და მომხმარებლამდე მიდის ინტერნეტის საშუალებით.

ეს ყველაფერი იცვლება. Blockchain-მა სრულიად სხვა მიმართულებით გაუხსნა გზა Web 3.0 აპლიკაციებს.

რა ხდის Web 3.0-ს განსხვავებულს
-------------------------------

Web 2.0 აპლიკაციებისგან განსხვავებით, Web 3.0 სრულიად გამორიცხავს შუამავლებს. არ არსებობს ცენტრალიზებული Database. არ არსებობს ერთი Web Server სადაც განთავსებულია კოდი.

ამის ნაცვლად შენ შეგიძლია გამოიყენო Blockchain აპლიკაციების შესაქმნელად დეცენტრალიზებულ გარემოში, რასაც ინტერნეტში ანონიმურად განთავსებული Node-ები უზრუნველყოფენ.

ასევე იმის ნაცვლად, რომ Medium-ის მსგავსი მარტივად კონტროლირებადი Back-End გქონდეს, Web 3.0-ში შეგიძლია შექმნა Smart Contract, რომელიც განსაზღვრავს შენი აპლიკაციის ლოგიკას და გაშვებული იქნება Blockchain-ში.

რაც შეეხება Front-End-ს, ის მეტწილად უცვლელი რჩება და ამის შესახებ მოგვიანებით ვისაუბრებთ.

ასე გამოიყურება Web 3.0 მარტივი არქიტექტურა:

Blockchain
----------

Ethereum Blockchain-ს ხშირად მოიხსენიებენ, როგორც მსოფლიო კომპიუტერს. ამას განაპირებობებს გლობალურად მისი ხელმისაწვდომობა. Ethereum Blockchain-ს უზრუნველყოფს peer to peer ქსელში განთავსებული Node-ები.

შეგვიძლია ვთქვათ, რომ Ethereum Blockchain შექმნილია ყველასთვის და წვდომა შეუძლია ნებისმიერს, ის არასდროს იქნება ვინმე კონკრეტულის საკუთრებაში, თუმცა ამავდროულად ის ეკუთვნის ყველას ქსელში.

Smart Contract
--------------

Smart Contract არის პროგრამა, რომელიც ეშვება Blockchain-ში და განსაზღვრავს ლოგიკას. Smart Contract-ები იწერება ისეთ High-Level ენებზე, როგორიც არის Solidity ან Vyper.

რადგან Smart Contract-ები გაშვებულია Blockchain-ში, ნებისმიერს აქვს საშუალება გამოიკვლიოს აპლიკაციის ლოგიკა.

Ethereum Virtual Machine (EVM)
------------------------------

EVM ასრულებს Smart Contract-ში აღწერილ ლოგიკას და უშვებს მას Blockchain-ში.

აუცილებელია ვთქვათ, რომ EVM-ს არ ესმის Solidity-სა და Vyper-ის მსგავსი High-Level ენები და საჭიროა კოდის კომპილირება.

Front-End
---------

როგორც აღვნიშნეთ, Front-End-ში განთავსებულია UI ლოგიკა და ასევე ის ახდენს კომუნიკაციას Smart Contract-ებთან.

Front-End-ისა და Smart Contract-ების კომუნიკაცია საკმაოდ დატვირთული თემაა და აუცილებელია გავშლაოთ.

როგორ ხდება კომუნიკაცია Front-End-სა და Smart Contract-ებს შორის.
-----------------------------------------------------------------

ჩვენი მიზანია Front-End-სა და Smart Contract-ს შორის კომუნიკაციით შესრულდეს ფუნქცია. თუმცა ამავდროულად არ უნდა დაგვავიწყდეს, რომ Smart Contract გაშვებულია Blockchain-ში, სადაც თითოეული Node ინახავს არსებულ მდგომარეობას.

შესაბამისად ჩვენ გვჭირდება მოვახდინოთ ცვლილება რომელიმე Node-ზე. რაც შემდეგ გავრცელდება მთელს ქსელზე.

არსებობს ტრანზაქციის გადაცემის ორი გზა:

1.  გაუშვა საკუთარი Node
    
2.  გამოიყენო სერვისის სახით მოწოდებული Node-ები. (infura, Alchemy…)
    

თუ გამოიყენებ Node პროვაიდერებს, საკმაოდ დიდ თავისტკივილს აიცილებ, რაც საკუთარი Node-ის გამართვასთან არის დაკავშირებული, ასევე Dapp-ის ზრდასთან ერთად საჭირო იქნება Node-ების დამატება. ინფრასტრუქტურის ზრდასთან ერთად საჭირო გახდება მუდმივი Devops ინჟინერი.

მოკლედ თავის ტკივილის ასაცილებლად უნდა გამოიყენოთ infura-სა დ Alchemy-ს მსგავსი Third Party Service-ები, რომლებსაც პროვაიდერებს (Providers) ეძახიან.

მას შემდეგ, რაც პროვაიდერის მეშვეობით დაუკავშირდი Blockchain-ს, შენ გაქვს შესაძლებლობა წაიკითხო Blockchain-ში განთავსებული მონაცემები. თუმცა თუ გინდა, რომ ჩანაწერი გააკეთო Blockchain-ში მოგიწევს მანამდე Sign ტრანზაქცია განახორციელო Private Key-ს მეშვეობით.

მაგალითად წარმოვიდგინოთ, რომ ჩვენი Dapp მომხმარებელს საშუალებას აძლევს წაიკითხონ და დაწერონ Blog-ები. Front-End-ში იქნება ღილაკი, რომელიც მომხმარებელს მისცემს საშუალებას სრულად წაიკითხოს ნებისმიერი Blog. მაგრამ, როდესაც მომხმარებელს სურს თავად დაწეროს Blog და გაუშვას Blockchain-ში, ჩვენი Dapp მას ავტორიზაციას იგივე Sign-ს მოთხოვს საკუთარი Private Key-ს მეშვეობით. მხოლოდ ამის შემდეგ გაეშვება ტრანზაქცია Blockchain-ში. წინააღმდეგ შემთხვევაში Node დაბლოკავს მას.

Metamask არის ერთ-ერთი Signer, რომელიც უმარტივებს აპლიკაციას Key მენეჯმენტს. პროცესი მარტივია, Metamask ინახავს მომხმარებლის Private Key-ს Browser-ში. Front-End მიმართავს Metamask-ს და მომხმარებელი Metamask-ში ადასტურებს ტრანზაქციას.

მონაცემთა ბაზები Blockchain-ში
------------------------------

Dapp-ის არქიტექტურა, რომელიც ჩვენ დავხატეთ ყველაფერს Blockchain-ში ინახავს. თუმცა პრაქტიკაში ყველაფრის Blockhain-ში შენახვა საკმაოდ ძვირია ნებისმიერი Network-ის შემთხვევაში.

გარდა ამისა არ არის მარტივი აუხსნა მომხმარებელს რომ მან უნდა გადაიხადოს თითოეული ქმედებისას.

ერთ-ერთი გამოსავალი ამ სიტუაციიდან არის დეცენტრალიზებული Off-Chain Storage-ები. (IPFS, Swarm)

ასე რომ ცენტრალიზებული ბაზისგან განსხვავებით, დეცენტრალიზებული Off Chain Storage-ები ანაწილებენ და ინახავენ მონაცემებს Peer to Peer ქსელში.

შესაბამისად დეცენტრალიზებულ Off Chain Storage-ებთან ერთად ჩვენი არქიტექტურა ასე გამოიყურება.

დიაგრამაზე შენიშნავდით, რომ Front-End არსად არ არის შენახული. ეს იმიტომ, რომ შეგვიძლია Front-End AWS-ზე განვათავსოთ როგორც Web 2.0 აპლიკაციის შემთხვევაში. თუმცა ეს ქმნის ცენტრალიზებას. რა მოხდება თუ AWS-ზე წვდომა შეგვეზღუდება? (ძნელად წარმოსადგენია მაგრამ მაინც)

თუ სრულად დეცენტრალიზებული აპლიკაცია Dapp გვსურს მაშინ უმჯობესია Front-End-იც დეცენტრალიზებულ Off Chain Storage-ზე განთავსდეს.

შესაბამისად ჩვენი არქიტექტურა ოდნავ შეიცვლება.

Blockchain-თან მიმართვები
-------------------------

აქამდე მხოლოდ Blockchain-ში ჩანაწერის გაკეთებაზე ვსაუბრობდით, თუმცა როგორ უნდა წავიკითხოთ მონაცემები Blockchain-დან?

ამისთვის ორი გზა არსებობს:

**Smart Contract Events**
-------------------------

შეგვიძლია გამოვიყენოთ Web3.js Library იმისთვის რომ მივმართოთ და მოვუსმინოთ Smart Contract Event-ებს. შეგვიძლია მოვუსმინოთ კონკრეტულ Event-ს და მის პასუხს ყოველ ჯერზე, როდესაც ის გაეშვება.

The Graph
---------

Smart Contract Event-ები კარგია თუმცა, როდესაც უკვე გაშვებულ Smart Contract-ზე აღმოაჩენ, რომ გჭირდება Event მოგიწევს ახალი Smart Contract-ის გაშვება Blockchain-ში.

სწორედ აქ შემოდის The Graph.

The Graph არის Off Chain ინდექსირება, რომელიც აადვილებს მონაცემების მოთხოვნას Blockchain-ში.

The Graph საშუალებას გვაძლევს განვსაზღვროთ, რომელი Smart Contract-ის ინდექსირება გვსურს, რომელ Event-ებს მოვუსმინოთ და ასე შემდეგ.

Blockchain მონაცემების ინდექსირებით The Graph საშუალებას გვაძლევს მოვითხოვოთ On Chain მონაცემები დაბალი დაყოვნებით.

შესაბამისად განახლებული არქიტექტურა გამოიყურება ასე:

შეჯამება
--------

უმეტესობისთვის, ვისაც შეხება არ ქონია Web 3.0-თან რთული იქნება გაიგოს როგორ მუშაობს ეს ჯაჭვი. თუმცა ვიმედოვნებ ცოტათი მაინც შეგიქმნით წარმოდგენას თუ რასთან და როგორ არის დაკავშირებული Dapp-ის შექმნა.

---

*Originally published on [Nebo](https://paragraph.com/@nebo/web-3-0)*