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

1) შესავალი

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

2) ძირითადი ტერმინები და დემარკაცია

ჭკვიანი კონტრაქტი არის პროგრამის კოდი, რომელიც შესრულებულია ბლოკჩეინში დეტერმინისტული წესების შესაბამისად.
ოპერატორი არის იურიდიული პირი, რომელიც განლაგებულია/უჭერს მხარს ოქმს ან თამაშს და განსაზღვრავს პოლიტიკას.
დეველოპერი/სტუდია - კოდის ან/და ჭკვიანი კონტრაქტების შემქმნელი.
ინფრასტრუქტურის პროვაიდერები - ორაკულები, ხიდები, VRF/შემთხვევითი შემთხვევა, ინდექსატორები, RPC.
Admin გასაღებები/როლები - გაფართოების უფლებები, პარამეტრები, „pause/kill-switch“.
DAO/გრანტის დამჭერები - მენეჯმენტში მონაწილე ტოქსინების/ხმების მფლობელები.
მომხმარებელი/მოთამაშე - მხარე, რომელიც ურთიერთქმედებს ხელშეკრულებასთან და ახორციელებს გარიგების/ცვალებადობის რისკებს.

3) პასუხისმგებლობის განაწილების მოდელი (ვინ არის პასუხისმგებელი რაზე)

პლატფორმის ოპერატორი

ადგილობრივი კანონების შესაბამისობა (iGaming/VASP/გადახდის რეჟიმები), KYC/AML/სანქციები;

ToS, Risk Disclosures, Responsible Gaming;

ინციდენტის მენეჯმენტი, კომუნიკაციები, კომპენსაციის მექანიზმები, ლოგების შენახვა.

დეველოპერი/სტუდია

კოდის ხარისხი, აუდიტი და ტესტის საფარი;

გაფართოებებისა და მიგრაციების თანმხლები, უიღბლო. საიდუმლოებების შენახვა;

ბაღბაუნტი, Responsible Disclosure, პოსტ-მორტის ანალიზი.

ორაკულის/ხიდების პროვაიდერები/VRF

SLO/წვდომა, ფიდების სისწორე და ანტი-მანიპულაციის ზომები;

სახელშეკრულებო გარანტიები და პასუხისმგებლობის შეზღუდვები (cap), ინციდენტების ჟურნალი, SLA.

ვალიდატორები/მაინერები/ქსელი

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

მომხმარებელი

რისკების დამოუკიდებელი შეფასება, პირადი გასაღებების დაცვა, ადგილობრივი კანონების დაცვა;

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

DAO/ტოქსინების მფლობელები (თუ მთავრობა)

რისკის პარამეტრების მიღება (ლიმიტები, საკომისიო), განახლება, გადაუდებელი გადაწყვეტილებები.

4) „კოდი, როგორც კანონი“ vs „კოდი, როგორც ხელშეკრულების ნაწილი“

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

1. ინტერპრეტაციის პრიორიტეტი (ToS> სპეციფიკაცია> კოდი? ან პირიქით - მკაფიო გამონაკლისებით);

2. როგორ არის განმარტებული აშკარა შეცდომები (mistake) და „უყურადღებო სახელმწიფოები“;

3. როდესაც გამოტოვება/პატჩ/პაუზა ნებადართულია და ვინ უფლებამოსილია მოქმედება.

5) განახლება, ადმინ გასაღებები და ნდობა

როლების გამჭვირვალობა: ჩამოთვალეთ მისამართები 'owner', 'admin', 'guardian', მიუთითეთ რომელი მეთოდები არის ხელმისაწვდომი ყველა როლისთვის.
Timelock & multi-sig: განახლება შეფერხებები (მაგალითად, 24-72 საათი) და მრავალსაფეხურიანი უფლებები ამცირებს ბოროტად გამოყენების რისკს.
განვითარებადი სახლი/კილ-სვიტჩი: გამოყენების რეგულაციები, კრიტერიუმები (კრიტიკული დაუცველობა, ორაკულის კომპრომისი), შეტყობინებისა და განახლების პროცედურა.
Proxy კონტრაქტები და მიგრაცია: პროცესის დოკუმენტირება, საშუალებას მისცემს მომხმარებლებს მიაღწიონ ლოგიკის შეცვლას (grace period).
ცვალებადობის დათქმა: თუ ხელშეკრულება არის immutable, მიუთითეთ შეზღუდვები და შედეგები (აქტივების მიგრაციის გარეშე კრიტბაგების შეკეთების შეუძლებლობა).

6) გარე დამოკიდებულება და კასკადის რისკები

ფასების ორაკულები და VRF: მანიპულაციებისგან დაცვა (TWAP, შენიშვნები, წყაროების კვორუმი), SLA ხელშეკრულებები და პასუხისმგებლობის შეზღუდვები.
ხიდები/ხიდები: ყველაზე დიდი ისტორიული დანაკარგები უკავშირდება ხიდებს - გამოიყენეთ TVL ლიმიტები, დაზღვევა, ეტაპობრივი გამომავალი ლიმიტები.
RPC/ინდექსატორები: პროვაიდერების, ჯანმრთელობის შემოწმებების და ფოლბეკების დუბლირება.
Frontend/დომენი: შემცვლელი დაცვა (DNSSEC, subresource integrity), ხელშეკრულებების საჯარო მისამართები, ხელშეკრულებასთან ურთიერთქმედების ოფლაინ-გზა.

7) რისკები და მათი კვალიფიკაცია

ტექნიკური: დაუცველობა, ლოგიკის შეცდომები, re-entrancy, გადატვირთვა, არასწორი დამრგვალება, MEV/წინა ჭრილობა.
ეკონომიკური: ბაზრის/ორაკულის მანიპულირება, „ბანკი რუნი“, გადახდისუუნარო ტოკენომიკა.
ოპერაციული: admin გასაღებების დაკარგვა, CI/CD- ის კომპრომისი, ადამიანის ფაქტორი.
იურიდიული: უსამართლო რეკლამა, ლიცენზიის არარსებობა, სანქციების დარღვევა/AML, მომხმარებელთა დაცვა.
ფორსმაჟორი web3: შეტევები L1/L2- ზე, გრძელი გარედან ქსელი, „უსაფრთხო“ მძიმე ჩანგალი, კატასტროფული დამოკიდებულების შეცდომები.

8) პასუხისმგებლობის შეზღუდვა და განაწილება (სახელფასო პუნქტები)

• Disclaimer რისკები (ცვალებადობა, ჭკვიანი კონტრაქტები, მესამე მხარის დამოკიდებულება, სახსრების სრული დაკარგვის რისკი).
• Liability Limitation (cap): საერთო პასუხისმგებლობის შეზღუდვა კომისიების/შემოსავლის ზომით X თვის ან ფიქსირებული cap.
• No consequential damages: არაპირდაპირი ზარალის გამორიცხვა (დაკარგული მოგება და ა.შ.).
• Risk assumption: მომხმარებლის მიერ რისკების შეგნებული მიღების დადასტურება.
• დამოუკიდებელი: ოპერატორის განთავისუფლება კანონის მომხმარებლის/ToS- ის მიერ დარღვევით გამოწვეული მოთხოვნებისგან.
• Force-majeure (web3 ვერსია): ქსელის გაუმართაობა, კონსენსუსის შეტევები, დამოკიდებულების კრიტიკული დაუცველობა, რეგულატორების ქმედებები.
• Right to suspend/pause: უფლება დროებით შეაჩეროს ოპერაციები უსაფრთხოების საფრთხის ქვეშ.

9) ინციდენტის მენეჯმენტი და კომპენსაცია

Policy & Playbook: საკონტაქტო არხები, პირველადი შეტყობინების თარიღები (მაგალითად, T + 24ch), სტატუსები, აფდეიტები.
ინციდენტების სეგმენტი: 'P0/P1/P2' გავლენას ახდენს სახსრებზე/წვდომაზე.
კომპენსაციის მექანიზმები: სარეზერვო აუზი, დაზღვევა, საგრანტო ანაზღაურება DAO- ს საშუალებით, დაზარალებულთა აღდგენის პრიორიტეტი.
post-mortem: საჯარო მოხსენება დროულად, root cause, კორექტირების ზომები.
Bug Bounty & Responsible Disclosure: დათქმა კეთილსინდისიერი გამჟღავნების, არხების, ჯილდოს დონის შესახებ.

10) Governance и DAO

ვის ეკუთვნის პასუხისმგებლობა? თუ გადაწყვეტილებებს იღებს DAO, დააფიქსირეთ იურიდიული „წარმომადგენლობა“ (ფონდი/LLC/ასოციაცია) და მისი როლი.
კვორუმი და განვითარებადი ნაკადები: ცალკეული ბარიერები კრიტიკული ქმედებებისთვის; დელეგატები მცველები სწრაფი რეაგირებისთვის.
ინტერესთა კონფლიქტი: დეველოპერების/მოვალეობების/ორაკულების შვილობილობის გამჟღავნება.
DAO სადავო საარბიტრაჟო მომხმარებლები: წინასწარი შუამდგომლობის ფანჯარა, შემდეგ არბიტრაჟი/სასამართლო.

11) იურისდიქცია, კანონის გამოყენება და დავის მოგვარება

მთავრობის კანონი + ფორუმი (საარბიტრაჟო/სასამართლო, ადგილი, ენა, პროცედურა).
სამომხმარებლო სამართლის დისპოზიციური ნორმები: B2C- ში, პირობების ნაწილი შეიძლება განისაზღვროს მომხმარებლის ქვეყნის უფლებით.
ონლაინ არბიტრაჟი/ODR: დავუშვათ, როგორც სწრაფი მექანიზმი მცირე დავებში.
კომბინირებული მოდელები: ტექნიკური აღდგენა on-chain + ოფშორული არბიტრაჟი ზიანის შესაფასებლად.

12) კონფიდენციალურობა და პირადი მონაცემები

თუ არსებობს ანგარიშები/CCC: პირადი პოლიტიკა, GDPR ბაზა, DPIA, მონაცემების მინიმიზაცია, შენახვის ვადა.
ეს მონაცემები საჯაროდ არის ცნობილი: დაწერეთ deanonymization რისკები, გაავრცელეთ PII ოფშორული.
წინა მხარის ტელემეტრიის შეგროვება მხოლოდ ლეგიტიმური ფუძით და opt-out/consent, სადაც საჭიროა.

13) Complaence მინიმუმ კრიპტო თამაშები/ოქმები რეალური ღირებულებით

ლიცენზიები/რეგისტრაცია: iGaming/VASP/MSB/გადახდის რეჟიმები გეოში.
KYC/AML/სანქციები: დონე, სახსრების წყაროები, Travel Rule (თუ გამოიყენება).
რეკლამა: ასაკობრივი ფილტრები, დისკლეიმერები, შეცდომაში შემყვანი დაპირებების აკრძალვა.
გადასახადები: GGR/კომისიების აღრიცხვა, გაცვლითი კურსის განსხვავებები, ხაზინის ხაზინა.

14) დოკუმენტაცია და არტეფაქტები (შესაბამისი შენახვა)

Terms of Service + Risk Disclosure + Responsible Gaming (თუ გამოიყენება).
Smart-contract Specs (ინვარიანტები, პარამეტრების საზღვრები, განახლება).
Admin/Keys Policy (multi-sig, timelock, შენახვა, როტაცია).
უსაფრთხოების პოლიტიკა (აუდიტები, ტესტები, bug bounty, SCA/SSA).
Incident Response Policy + მომხმარებლის შეტყობინების შაბლონი.
Oracle/Bridge SLA + პასუხისმგებლობის ხელშეკრულების ლიმიტები.
Change Log & Post-mortems (საზოგადოებრივი ცვლილებების საცავი).

15) პასუხისმგებლობის მატრიცა (მაგალითი RACI)

16) გაშვების ჩეკის სია (მოკლე)

1. განსაზღვრეთ როლები/მისამართები უფლებებით, ჩართეთ timelock + multi-sig.
2. აღწერეთ განახლება პროცედურა და „pause/kill-switch“ ToS და README საცავებში.
3. ჩაატარეთ დამოუკიდებელი აუდიტი, ჩართეთ ბაგაუნტი, გამოაქვეყნეთ ანგარიში.
4. კონტრაქტის გაფორმება oracles/ხიდები SLA და TVL/O ლიმიტები.
5. ინვარიანტების მონიტორინგის კონფიგურაცია (TVL, ტყვიების დისბალანსი, ორაკულების შეფერხება).
6. ასახეთ Risk Disclosures, პასუხისმგებლობის შეზღუდვები (cap), force-majeure.
7. დამტკიცდეს Incident Policy და შეტყობინებების შაბლონი, რეზერვი კომპენსაციისთვის.
8. შესაბამისობის გადამოწმება (ლიცენზიები, KYC/AML, სანქციები, გადასახადები, რეკლამა).
9. მოამზადეთ მიგრაციის გეგმა.
10. პერიოდულად ჩაატარეთ თამაშის დღე/ქაოსის ტესტები და პოსტ-მორტემები.

17) შაბლონის წერტილები ToS/პოლიტიკოსისთვის (ფორმულირების ესკიზები)

• „ოპერატორს ან/და დანიშნულ მეურვეებს უფლება აქვთ გამოიყენონ სმარტ კონტრაქტების შესრულების დროებითი შეჩერება კრიტიკული დაუცველების გამოვლენის შემთხვევაში, რასაც მოჰყვა საჯარო მოხსენება და აღდგენის გეგმა“.

• "კონტრაქტების ლოგიკაში ცვლილებები ხორციელდება timelock- ის საშუალებით მინიმუმ N საათის განმავლობაში; ადმინისტრატორთა მისამართები და ცვლილებების ისტორია ქვეყნდება საცავში/საიტზე."

• „ოპერატორის მთლიანი პასუხისმგებლობა ნამდვილად ხელშეკრულებით შემოიფარგლება ბოლო N თვის განმავლობაში მომხმარებლის მიერ ფაქტობრივად გადახდილი კომისიების/გადახდების ოდენობით და არ შეიცავს არაპირდაპირი ზარალს“.

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

• „ჭკვიან კონტრაქტებთან ურთიერთქმედება დაკავშირებულია აქტივების სრული და შეუქცევადი დაკარგვის რისკთან კოდის დაუცველების, კონფიგურაციის შეცდომების და ბაზრის მანიპულირების გამო“.

(კოორდინირებული ფორმულირება ადგილობრივ ადვოკატთან; B2C- სთვის შესაძლებელია სავალდებულო დათქმები მომხმარებელთა უფლებების შესახებ.)

18) გლოსარიუმი

Timelock არის შეფერხება ძალაში შესვლამდე.
Multi-sig არის admin ოპერაციების მრავალსაფეხურიანი კონტროლი.
Kill-switch/Pause - ხელშეკრულებების შესრულების გადაუდებელი შეჩერება.
Invariant monitoring - პროტოკოლის ძირითადი თვისებების ავტომატური შემოწმება.
RACI არის პასუხისმგებლობის განაწილების მატრიცა.

დასკვნა

ჭკვიანი კონტრაქტების იურიდიული სტაბილურობა ემყარება სამ სვეტს: (1) მკაფიო როლები და პასუხისმგებლობის შეზღუდვები, რომლებიც ასახულია საზოგადოებრივ პოლიტიკოსებსა და ToS- ში; (2) ტექნიკური დისციპლინა - განახლება timelock/multi-sig, აუდიტი, ინვარიანტების მონიტორინგი, ინციდენტის მენეჯმენტი; (3) საიმედო შეთანხმებები გარე დამოკიდებულების პროვაიდერთან და სწორი დათქმები პასუხისმგებლობისა და ფორსმაჟორის შესახებ. ამ ელემენტების ერთობლიობა ამცირებს სადავო სიტუაციების ალბათობას და განსაზღვრავს მხარეთა ქცევის პროგნოზირებულ მოდელს, თუნდაც web3 გაურკვევლობის პირობებში.