Opside ქსელი წარუდგენს 3 ფენის არქიტექტურას ბლოკჩეინის აპისთვის…

ბლოკჩეინის მასშტაბურობა და შემოთავაზებული გადაწყვეტილებები უკვე ნახევარი ათწლეულის განმავლობაში იყო სოციალური მედიის საუბრის წინა პლანზე. მაგალითად, ისრაელის პროგრამული უზრუნველყოფის კომპანია Starkware და Ethereum-ის თანადამფუძნებელმა ვიტალიკ ბუტერინმა ცოტა ხნის წინ ისაუბრეს „Layer 3“-ის იდეაზე, როგორც ერთ-ერთ ასეთ გადაწყვეტაზე. Starkware ამბობს, რომ მრავალი ფენა 3 იქნება 2 ფენის თავზე და "ფრაქტალური ფენების" გადაწყვეტილებები შეიძლება აშენდეს Layer 3-ის თავზე. 

პროექტი Opside ახლახან გამოაქვეყნეს თავიანთი გეგმები სამ ფენიანი არქიტექტურისთვის. ეს დეველოპერებს საშუალებას მისცემს შექმნან ბლოკჩეინის აპლიკაციები, რომლებსაც ექნებათ წვდომა უფრო სწრაფ სიჩქარეზე და იაფ ტრანზაქციებზე. ეს შესაძლებელი გახდა Opside ჯაჭვის საშუალებით, რომელსაც უწოდებენ Layer 2 გადაწყვეტას, რადგან ის ზის მრავალი ფენის 1 პლატფორმის თავზე (როგორიცაა Ethereum, Binance Chain, Bitcoin და ა.შ.) და იყენებს მათ, როგორც ანგარიშსწორების ფენას. „Layer 3“ ფუნქციონალობა ამას კიდევ უფრო შორს მიჰყავს, რაც დეველოპერებს საშუალებას აძლევს დაატრიალონ „შეკრება, როგორც სერვისი“. ეს არქიტექტურა აძლევს Layer 2-ს აქტივების უფრო ყოვლისმომცველ დიაპაზონს ხიდებიდან და შესაძლებლობას, განუსაზღვრელი ვადით გაიზარდოს შეკრებიდან. 

მრავალი ჯაჭვის შორის საკონტრაქტო ზარების დასამუშავებლად, ოპიდი შეიმუშავა პროტოკოლი ყველა საკონტრაქტო ზარის დასამუშავებლად. ასევე დამუშავების პროცესშია DAO ხმის მიცემა, რომელიც Opside საზოგადოებას აძლევს ხმის მიცემის საშუალებას, თუ რომელი საჯარო ჯაჭვები გამოიყენოს Layer 1 დასახლებისთვის. 

Layer 2 გადაწყვეტილებები დამოკიდებულია მათი Layer 1 კოლეგის დეცენტრალიზაციაზე, რათა უზრუნველყოს უფრო სწრაფი ტრანზაქციის დრო და დაბალი გაზის გადასახადი. როგორც ჩანს, ბლოკჩეინის თემების უმეტესობისთვის მისაღებია ცენტრალიზებული ფენის არსებობა მათი პლატფორმის თავზე მანამ, სანამ ყოველი ტრანზაქცია განიხილება Layer 1 დონეზე. ეფექტურობა მიიღწევა ტრანზაქციების ნაკრების „შეფუთვით“ და მოგვიანებით გადახდით. 3 ფენა აძლიერებს ამ მოდელს, რაც კიდევ უფრო მეტ ხარჯების ეფექტურობას იძლევა მეორე ფენის ქსელის სიჩქარის შენარჩუნებისას. 

მე-3 ფენას აქვს ისეთი დაბალი ხარჯების შეთავაზების პოტენციალი, რომ 2 ფენის ქსელებზე აგებულ პროექტებსაც არ მოუწევთ საკუთარი 1-ლი ფენების განლაგება ანგარიშსწორების საფასურის შესამცირებლად. ამ აპლიკაციებს, როგორიცაა Axie და dYdX Decentralized Exchange, ამის გაკეთება მოუწიათ მხოლოდ იმიტომ, რომ მათი მოდელი დამოკიდებული იყო ყველაზე სწრაფ ტრანზაქციის დროზე და ყველაზე დაბალ საკომისიოზე. თუ განლაგებულია მე-3 ფენის გაერთიანებაზე, მას შეუძლია თავიდან აიცილოს კიდევ ერთი ბლოკჩეინის საჭიროება.

Layer1: მრავალჯაჭვიანი ხიდები

Opside მხარს უჭერს უფრო სწრაფ და იაფ დეცენტრალიზებულ Liquidity-Bridge-ს, რათა მიაღწიოს აქტივების თავსებადობას მეტ ჯაჭვებში. Liquidity-Bridge შედგება უნებართვო კვანძებისგან, რომლებიც მიაღწიეს კონსენსუსს ჯვარედინი ჯაჭვური შეტყობინებების შესახებ MPC-ის მეშვეობით. ლიკვიდურობის აუზს მოაქვს უფრო სწრაფი სიჩქარე და მხარს უჭერს უფრო მეტ საჯარო ქსელს და მათ აქტივებს.

გარდა ამისა, Opside დაამყარებს კავშირებს აქტივების ფენის სხვადასხვა საჯარო ჯაჭვებთან დაუსაბუთებელი ZK-Bridge-ის მეშვეობით. სხვა ხიდების სქემებთან შედარებით, ZK-Rollup სქემა მოიცავს უფრო ZK-proof სისტემებს. ჯვარედინი ოპერაციების დროს აუცილებელია ZK Proofs-ის გენერირება, რათა უზრუნველყოს შესრულების პროცესის სისწორე, გარდა ზოგადი „აღსრულებისა“. ZK-Bridge-ის დეპოზიტისა და გატანის ოპერაციები "მყარდება" წრედ და მიკროსქემის ლოგიკა მთლიანად გამოვლენილია.

Layer2: Rollup-მეგობრული ჯაჭვი

Opside ჯაჭვი, ან Layer 2, არის EVM-თან თავსებადი და დაჯგუფების მეგობრული ჯაჭვი. Opside ჯაჭვი გააკეთებს ღრმა ოპტიმიზაციას შეკრებებისთვის.

მშობლიური გაერთიანება გარკვეულწილად მსგავსია პოლკადოტის არქიტექტურას. მას შემდეგ რაც გაერთიანება დაარეგისტრირებს სლოტს, შეკრება ხდება მშობლიური შეკრება. ამის საპირისპიროდ, პოლკადოტის არქიტექტურას აქვს მინუსი, რომ პარაჯაინის კონსენსუსი დამოკიდებულია ვალიდატორების დანიშნულ კომპლექტზე. Იქ არის კავშირი უსაფრთხოებასა და ვალიდატორების რაოდენობას შორის. თუ რამდენიმე ვალიდატორი გადის ხაზგარეშე, პარაჩაინები, რომელთა ვალიდატორების ჯგუფები ძალიან მცირეა ბლოკის ვალიდაციისთვის, გამოტოვებენ ამ ბლოკებს, ან თუნდაც გაჩერდებიან სანამ სიტუაცია არ მოგვარდება. Opside-ს არ აქვს ეს პრობლემა, რადგან ფენა 2 აგროვებს მონაცემებს მე-3 ფენის ყველა მშობლიური გაერთიანებიდან და ამოწმებს ყველა zk მტკიცებულებას. Opside Chain არის უფრო უსაფრთხო და დეცენტრალიზებული, მასზე ყველა შეკრებით, როგორც უფრო მჭიდრო მთლიანობით, იზიარებს იგივე კონსენსუსის ფენას.

არსებობს 64 წინასწარ განლაგებული კონტრაქტი, როგორც „შეკრების სლოტები“, რომლებიც გამოიძახება უშუალოდ შეკრებიდან მიღებული სერიული და მტკიცებულებითი ტრანზაქციებით. ეს სლოტები გამოიძახებს წინასწარ შედგენილ კონტრაქტს მტკიცებულების გადამოწმებისთვის და განაახლებს ადგილობრივ სახელმწიფო ფესვებს, თუ ეს წარმატებული იქნება. წინასწარ შედგენილ კონტრაქტს შეუძლია დააჩქაროს ნულოვანი ცოდნის მტკიცებულებების გადამოწმება ბინარულ კოდებში ოპტიმიზაციით.

Opside არქიტექტურის 2 და 3 ფენა იზიარებს a კონსენსუსის მექანიზმი PoS და PoW ჰიბრიდით.

• PoS: მე-2 ფენაზე, ნებისმიერს შეუძლია გახდეს ვალიდატორი ფსონებით, შემდეგ კი აქვს შესაძლებლობა შექმნას Opside Chain-ის ბლოკები. PoS დასამტკიცებელია და ვალიდატორები პერიოდულად წარუდგენენ PoS მტკიცებულებებს 1-ლ ფენას. ვალიდატორებს შეუძლიათ მიიღონ ბლოკის ჯილდო და ფსონის ჯილდო PoS-ის ამ ნაწილისთვის.
• PoW: მე-2 ფენის ვალიდატორები არა მხოლოდ აწარმოებენ Opside Chain ბლოკებს, არამედ გამოიმუშავებენ zk მტკიცებულებას მე-3 ფენის თითოეული მშობლიური გაერთიანებისთვის, წესების მიხედვით. PoVP. ვალიდატორები მიიღებენ IDE ჯილდოს zk მტკიცებულების წარმატებული გენერირებისთვის, რომელიც გარკვეულწილად მსგავსია PoW-ის. ვალიდიატორებს შეუძლიათ მიიღონ დამატებითი ბონუსი ჯილდოს ამ ნაწილზე, სისტემურ კონტრაქტში მეტი ჟეტონის განთავსებით.

რაც მთავარია, Opside-ში, სლოტების რეგისტრაციის დასრულების შემდეგ, მშობლიური კრებულები ერთმანეთს უზიარებენ მსოფლიო სახელმწიფო ხეს და იმავე გლობალურ შეტყობინებების რიგს. აქედან გამომდინარე, Opside-ში შესაძლებელია მშობლიური cross-rollup თავსებადობა. წარმოიდგინეთ, რომ გსურთ დაასესხოთ USDC სესხის კონტრაქტზე A Rollup-ში და შემდეგ გადადით DEX-ში B Rollup-ში, რათა ივაჭროთ BTC-ის შესაძენად. Opside-ზე აღარ გჭირდებათ აქტივების ამოღება A-დან L1-მდე და შემდეგ მათი გადატვირთვა L1-დან B-მდე. ამის ნაცვლად, შეგიძლიათ დარეკოთ შეკრების B კონტრაქტის მეთოდი პირდაპირ A-ში. ეს მთელ პროცესს ბევრად უფრო აჩქარებს. უფრო იაფი და უსაფრთხო.

ფენა 3: დეცენტრალიზებული ZK-შეკრება

მესამე ფენაში, Opside მხარს უჭერს დეველოპერებს განათავსონ საკუთარი შეკრებები, ხოლო Opside ასევე უზრუნველყოფს ა დეცენტრალიზებული გადაწყვეტა ზემოთ ხსენებულ RaaS-ზე დაყრდნობით. დეველოპერებს შეუძლიათ თავისუფლად აირჩიონ რომელი მიიღონ. ეს გადაწყვეტა არ არის სანდო და უნებართვო. ნებისმიერს შეუძლია წარადგინოს L2 პარტიები და მტკიცებულებები L1-ში.

შეჯამებისთვის, Opside-ის „საბაზისო ფენის <- opside <- rollup“ არქიტექტურას აქვს აქტივების მრავალფეროვნებისა და უსასრულო მასშტაბურობის უპირატესობა. ეს შეიძლება იყოს კიდევ ერთი არჩევანი web3 აპლიკაციების მასშტაბურობის პრობლემების გადასაჭრელად. ძვირად დაფუძნებულ შრე 2-ებთან შედარებით, ის უფრო შესაფერისია მაღალი გამტარუნარიანობის აპლიკაციებისთვის, როგორიცაა თამაშები.

უარი პასუხისმგებლობაზე: ეს სტატია მოწოდებულია მხოლოდ ინფორმაციული მიზნებისთვის. ის არ არის შემოთავაზებული ან მიზნად ისახავს გამოყენებას იურიდიულ, საგადასახადო, საინვესტიციო, ფინანსურ ან სხვა რჩევად.