Oriģinālnosaukums: 7 Sanity Checks Before Designing a Token
Autors: Guy Wuollet
Sastādījusi: Keitija Gu, Odaily Planet Daily
Žetoni ir spēcīgs jauns primitīvs, ko var definēt dažādos veidos. Žetonu dizaina telpa ir bagāta, taču mēs joprojām esam izpētes sākuma stadijā.
Patiesībā daudzām komandām ir grūti atrast "pareizo" marķiera dizainu saviem projektiem. Tomēr nozarei trūkst pārbaudīta dizaina ietvara, tāpēc vēlākās paaudzes atkārtoti saskaras ar tādiem pašiem izaicinājumiem kā viņu priekšgājēji. Par laimi, ir (daži) agrīni veiksmīga marķiera dizaina piemēri. Visefektīvākajiem marķieru modeļiem ir elementi, kas ir unikāli to mērķiem, taču lielākajai daļai nepilnīgo marķieru noformējumu ir dažas kopīgas kļūdas. Tāpēc šajā rakstā tiks apspriests, kāpēc mums vajadzētu apsvērt žetonu izpēti un dizainu, nevis tikai “žetonu ekonomiku”, un uzskaitīti septiņi padomi, kā izvairīties no kļūmēm.
#1 Noskaidrojiet marķieru dizaina mērķus
Lielākā marķiera dizaina problēma ir sarežģīta marķiera modeļa izveide, pirms mērķis ir skaidrs. Vispirms ir jānosaka mērķis un jāpārliecinās, ka visa komanda to pilnībā saprot: kas tas ir, kāpēc tas ir svarīgi un ko jūs patiešām vēlaties paveikt? Nespēja precīzi definēt mērķus bieži noved pie pārprojektēšanas un laika izšķiešanas. Skaidri mērķi palīdz arī izvairīties no problēmas “izveidot simbolisku ekonomiku, lai izstrādātu simbolisku ekonomiku”, kas ir izplatīta parādība dažos simboliskos ekonomiskajos projektos.
Turklāt mērķim jābūt ap pašu marķieri, taču tas bieži tiek ignorēts. Skaidru mērķu piemēri:
Izveidojiet spēli ar marķiera modeli, kas nodrošina optimālu mērogojamību un atbalsta modelēšanu.
DeFi protokols cer izveidot marķiera modeli, kas saprātīgi sadala risku starp dalībniekiem.
Reputācijas protokola izstrāde, kas garantē naudu, nevar tieši aizstāt reputāciju (piemēram, atdalot likviditāti no reputācijas signāliem).
Izveidojiet krātuves tīklu, kas nodrošina, ka faili ir pieejami ar zemu latentumu.
Izstrādājiet stingru tīklu, kas nodrošina maksimālu ekonomisko drošību.
Izveidojiet pārvaldības mehānismu, kas rada patiesas lietotāja preferences vai palielina līdzdalību.
Saraksts turpinās un turpinās. Ļaujiet marķierim atbalstīt jebkuru lietošanas gadījumu un sasniegt jebkuru mērķi, nevis pretējo.
Tātad, kā sākt definēt skaidru mērķi? Precīzi definēti mērķi parasti nāk no "projekta misijas". Lai gan "projekta misija" mēdz būt augsta līmeņa un abstrakta, mērķiem jābūt konkrētiem un jāsamazina līdz to pamatformai.
Kā piemēru ņemsim EIP-1559. Roughgarden noteica skaidru EIP-1559 mērķi: "EIP-1559 ir jāuzlabo lietotāju pieredze, izmantojot vienkāršu izmaksu aprēķinu "skaidras labākās cenas" veidā ārpus strauja pieprasījuma pieauguma periodiem.
Viņš turpināja piedāvāt vēl vienu skaidru mērķi: "Vai mēs varam pārveidot Ethereum darījumu maksas mehānismu, lai darījuma gāzes cenu noteikšana būtu "zīdaināka", piemēram, iepirkšanās vietnē Amazon. Ideālā gadījumā tas ir cenu publicēšanas mehānisms, kas nozīmē, ka katrs lietotājs var pieņemt vai dot? paaugstina gāzes cenu."
Abiem piemēriem kopīgs ir tas, ka jūs nosaucat augsta līmeņa mērķi, sniedzat atbilstošu analoģiju, lai palīdzētu citiem saprast jūsu mērķi, un pēc tam turpiniet ieskicēt dizaina risinājumu, kas vislabāk atbalsta šo mērķi.
#2 Novērtējiet esošo darbu, pamatojoties uz pamatprincipiem
Veidojot kaut ko jaunu, ieteicams sākt ar kaut ko jau esošu. Novērtējot esošos protokolus un esošo literatūru, tie ir jānovērtē objektīvi, pamatojoties uz to tehniskajām īpašībām.
Žetonu modeļi bieži tiek novērtēti, pamatojoties uz marķiera cenu vai saistītā projekta popularitāti. Šie faktori var nebūt saistīti ar marķiera modeļa spēju sasniegt izvirzītos mērķus. Vērtēšana, popularitāte vai citi vienkāršoti marķiera modeļa novērtēšanas veidi var novest pie tā, ka celtnieki izvēlas “apvedceļus”. Ja pieņemat, ka citi marķieru modeļi darbojas pareizi, lai gan patiesībā tie nedarbojas, varat izveidot "pēc būtības kļūdainu" marķiera modeli.
# 3 Noskaidrojiet savus pieņēmumus
Padariet savus pieņēmumus skaidrus. Ja koncentrējaties uz monētas izgatavošanu, ir viegli uzskatīt pamatpieņēmumus par pašsaprotamiem. Ir arī viegli nepareizi formulēt pieņēmumus, kurus jūs patiešām veicat.
Ņemiet, piemēram, jaunu protokolu, kas pieņem, ka tā aparatūras vājā vieta ir skaitļošanas ātrums. Šī pieņēmuma padarīšana par marķiera modeļa daļu (piemēram, ierobežojot aparatūras izmaksas, kas nepieciešamas, lai piedalītos protokolā), var palīdzēt saskaņot dizainu ar vēlamo darbību.
Tomēr, ja protokolu un marķieru izstrādātāji skaidri neizsaka savus pieņēmumus vai viņu izteiktie pieņēmumi ir nepareizi. Dalībniekiem, kuri apzinās šo neatbilstību, ir iespēja iegūt vērtību no protokola. Hakeri parasti ir cilvēki, kuri saprot sistēmu labāk nekā cilvēki, kas to sākotnēji izveidoja.
Precizējot savus pieņēmumus, cilvēkiem būs vieglāk saprast jūsu marķiera dizainu un nodrošināt tā pareizu darbību. Ja neizteiksiet savu hipotēzi skaidru, jūs nevarēsit pārbaudīt savu hipotēzi.
# 4 Pārbaudiet savus pieņēmumus
Ir tāds teiciens: “Tas nav tas, ko tu nezini, tas, par ko tu esi pārliecināts, ka nezina.
Žetonu modeļi bieži izdara virkni pieņēmumu. Šī pieeja daļēji izriet no bizantiešu sistēmas dizaina, kas bija blokķēdes iedvesma. Sistēma izdara pieņēmumu un izveido funkciju, kas, ja pieņēmums ir patiess, garantē noteiktu rezultātu. Piemēram, Bitcoin garantē aktivitāti sinhronā tīkla modelī, garantējot konsekvenci, ja 51% no jaucējvaras tīklā ir godīgi. Vairākas mazākas blokķēdes ir cietušas 51% uzbrukumu, pārkāpjot Satoshi konsensā noteikto godīguma pieņēmumu skaitu, lai blokķēdes darbotos pareizi.
Žetonu izstrādātāji var pārbaudīt savus pieņēmumus dažādos veidos. Stingra statistiskā modelēšana, bieži vien uz aģentiem balstītu modeļu veidā, var palīdzēt pārbaudīt šīs hipotēzes. Hipotēzes par lietotāju uzvedību bieži var arī pārbaudīt, runājot ar lietotājiem, un vēl labāk, novērojot, ko cilvēki patiesībā dara (nevis saka, ko viņi dara). Veiksmīgas validācijas iespējamība ir lielāka, jo īpaši ar stimulētiem testa tīkliem, kas rada empīriskus rezultātus smilškastes vidē. Oficiāla validācija vai intensīva auditēšana arī palīdzēs nodrošināt, ka kodu bāze darbojas, kā paredzēts.
#5 Nosakiet “abstraktos šķēršļus”
"Abstrakcijas barjera" ir saskarne starp dažādiem sistēmas vai protokola slāņiem. To izmanto, lai atdalītu dažādas sistēmas sastāvdaļas, ļaujot katru komponentu projektēt, ieviest un modificēt neatkarīgi. Skaidras abstrakcijas barjeras ir noderīgas visās inženierzinātņu jomās, jo īpaši programmatūras projektēšanā, taču tās ir vēl vairāk nepieciešamas decentralizētai attīstībai un lielām komandām, kas veido sarežģītas sistēmas, kuras nevar saprast neviens indivīds.
Žetonu dizainā abstrakcijas šķēršļu attīrīšanas mērķis ir samazināt sarežģītību. Samazinot (iekšējo) atkarību starp dažādiem marķiera modeļa komponentiem, var iegūt tīrāku kodu, mazāk kļūdu un labāku marķiera dizainu.
Piemēram, daudzas blokķēdes veido lielas inženieru komandas. Komanda var izdarīt pieņēmumus par aparatūras izmaksām laika gaitā un izmantot to, lai noteiktu, cik daudz kalnraču iegulda aparatūru blokķēdē par noteiktu marķiera cenu. Ja cita komanda paļaujas uz marķiera cenu kā parametru, bet nezina pirmās komandas pieņēmumus par aparatūras izmaksām, tā var viegli izdarīt pretrunīgus pieņēmumus.
Lietojumprogrammas slānī skaidras abstrakcijas barjeras ir būtiskas, lai panāktu kompozīciju. Tā kā vairāk protokolu tiek apvienoti viens ar otru, spēja pielāgoties, veidot, paplašināt un remiksēt kļūs tikai svarīgāka. Lielākas kompozīcijas sniedz lielākas iespējas, bet arī lielāku sarežģītību. Kad lietojumprogrammas vēlas rakstīt, tām ir jāsaprot izmantotā kompozīcijas protokola detaļas.
Necaurredzami pieņēmumi un saskarnes dažkārt var radīt neskaidras kļūdas, īpaši agrīnajos DeFi protokolos. Izplūdušās abstrakcijas barjeras arī palielina saziņas efektivitāti, kas nepieciešama starp komandām, kas strādā pie dažādiem protokola komponentiem, tādējādi pagarinot izstrādes laiku. Neskaidrie abstrakcijas šķēršļi arī palielina protokola sarežģītību, apgrūtinot tā mehānikas pilnīgu izpratni.
Izveidojot skaidrus abstraktus šķēršļus, marķieru izstrādātāji var vieglāk paredzēt, kā konkrētas izmaiņas ietekmēs katru marķiera dizaina daļu. Skaidras abstrakcijas barjeras arī atvieglo marķiera vai protokola paplašināšanu un veido iekļaujošāku un mērogojamāku Builder kopienu.
#6 Samaziniet atkarību no ārējiem parametriem
Ārējie parametri nav raksturīgi sistēmai, bet var ietekmēt vispārējo veiktspēju un panākumus, piemēram, skaitļošanas resursu izmaksas, transakciju apjomu vai latentumu marķiera modeļa izveides sākumposmā.
Bet, ja marķiera modelis darbojas tikai tad, ja parametri tiek turēti ierobežotā diapazonā, var rasties neparedzēta darbība. Piemēram, protokols, kas pārdod pakalpojumus un nodrošina atlaides fiksētas marķiera atlīdzības veidā, var būt vairāk vērts nekā pakalpojuma izmaksas, ja marķiera cena ir negaidīti augsta. Šajā gadījumā ir diezgan ekonomiski izdevīgi iegādāties neierobežotus pakalpojumus no protokola, kas pilnībā izmantos simbolisko atlīdzību un pakalpojumu priekšrocības.
Citu piemēru var teikt, ka decentralizētie tīkli bieži paļaujas uz kriptogrāfijas algoritmiem vai skaitļošanas mīklām, kuras ir grūti, bet ne neiespējami atrisināt. Grūtības parasti ir atkarīgas no eksogēna mainīgā lieluma, piemēram, cik ātri dators var aprēķināt jaucējfunkciju vai nulles zināšanu pierādījumu. Piemēram, ir protokols, kas pieņem, cik ātri var aprēķināt doto jaucējfunkciju, un attiecīgi maksā marķiera atlīdzību. Ja kāds izgudro jaunu veidu, kā ātrāk aprēķināt jaukšanas funkciju, vai vienkārši problēmas risināšanai ir pārāk lieli resursi, kas ir nesamērīgi ar faktisko darbu sistēmā, viņš var tikt apbalvots ar negaidīti milzīgiem žetoniem.
#7 Atkārtoti apstipriniet pieņēmumus
Žetona izstrādei vajadzētu līdzināties sacīkstes sistēmas izveidei. Lietotāja uzvedība mainīsies, mainoties marķiera darbības veidam.
Izplatīta kļūda ir marķiera modeļa pielāgošana, nenodrošinot, ka patvaļīga lietotāja rīcība joprojām rada pieņemamus rezultātus. Nedomājiet, ka lietotāja uzvedība paliks nemainīga marķiera modeļa izmaiņu dēļ. Parasti šāda veida kļūdas rodas vēlīnā izstrādes procesā, kad kāds ir pavadījis daudz laika, lai definētu marķiera mērķi, definētu tā funkcionalitāti un apstiprinātu to, lai nodrošinātu, ka tas darbojas, kā paredzēts. Pēc tam viņi identificēja īpašu gadījumu un mainīja marķiera dizainu, lai tas atbilstu tam, bet aizmirsa atkārtoti apstiprināt visu marķiera modeli. Novēršot vienu īpašu gadījumu, tie rada citas (vai vairākas citas) neparedzētas sekas.
Atcerieties, ka jūsu smagajam darbam nevajadzētu iet velti. Ikreiz, kad projekts maina marķiera modeli, atkārtoti pārbaudiet, vai tas darbojas, kā paredzēts.