原文标题：Vai Ethereum būtu pareizi protokolā iekļaut vairāk lietu?
Autors: Vitāliks Buterins
Sastādījis: Nian Yin Si Tang, Planet Daily
Kopš Ethereum projekta sākuma ir bijusi spēcīga filozofija, cenšoties padarīt Ethereum kodolu pēc iespējas vienkāršāku un sasniegt to, cik vien iespējams, izveidojot protokolus. Blokķēdes telpā bieži tiek uzskatīts, ka diskusijas par "balstīšanos uz L1" un "koncentrēties uz L2" galvenokārt ir saistītas ar mērogošanu, taču patiesībā pastāv līdzīgas problēmas vairāku Ethereum lietotāju vajadzību apmierināšanā: digitālo līdzekļu apmaiņa, privātums. , lietotājvārdi, uzlabota šifrēšana, konta drošība, cenzūras izturība, progresīva aizsardzība un daudz kas cits. Tomēr nesen ir bijuši daži piesardzīgi mēģinājumi iekļaut vairāk šo funkciju Ethereum pamatprotokolā.
Šajā rakstā tiks aplūkoti daži no sākotnējās minimālās iekapsulēšanas filozofijas filozofiskajiem pamatojumiem, kā arī daži nesenie domāšanas veidi par šīm idejām. Mērķis būs sākt veidot sistēmu, lai labāk noteiktu iespējamos mērķus, kuros varētu būt vērts apsvērt noteiktas funkcionalitātes iekapsulēšanu.
Agrīna protokola minimālisma filozofija
Tolaik pazīstamā kā "Ethereum 2.0" agrīnajā vēsturē bija liela vēlme izveidot tīru, vienkāršu un skaistu protokolu, kas pēc iespējas mazāk centās pilnveidot sevi un gandrīz visu šo darbu atstāja lietotāju ziņā. Ideālā gadījumā protokols ir tikai virtuāla mašīna, un bloka apstiprināšana ir tikai virtuālās mašīnas izsaukums.
Šī ir aptuvenā tāfeles diagrammas rekonstrukcija, ko es un Gevins Gevins View More Wood zīmējām 2015. gada sākumā, kad runāju par to, kā izskatīsies Ethereum 2.0.
"Stāvokļa pārejas funkcija" (funkcija, kas apstrādā bloku) būs tikai viens VM izsaukums, un visa pārējā loģika notiks, izmantojot līgumus: daži sistēmas līmeņa līgumi, bet galvenokārt lietotāja nodrošināti līgumi. Ļoti jauka šī modeļa iezīme ir tā, ka pat visu cieto daļu var raksturot kā vienu darījumu ar bloka procesora līgumu, kas tiks apstiprināts ārpus ķēdes vai ķēdes pārvaldības un pēc tam jaunināta atļauja darboties.
Šīs 2015. gada diskusijas īpaši attiecas uz divām jomām, kuras mēs apsveram: konta abstrakciju un mērogošanu. Mērogošanas gadījumā ideja ir mēģināt izveidot maksimāli abstraktu mērogošanas veidu, kas šķiet dabisks iepriekš minētās diagrammas paplašinājums. Līgumi var izsaukt datus, kas netiek glabāti vairumā Ethereum mezglu, un protokols to atklās un atrisinās zvanu, izmantojot kādu ļoti vispārīgu paplašinātu skaitļošanas funkcionalitāti. No virtuālās mašīnas viedokļa zvans nonāks atsevišķā apakšsistēmā un pēc kāda laika maģiski atgriezīs pareizo atbildi.
Mēs īsi izpētījām šo ideju, taču ātri no tās atteicāmies, jo bijām pārāk koncentrējušies uz to, lai pierādītu, ka ir iespējama jebkāda veida blokķēdes mērogošana. Lai gan, kā mēs redzēsim vēlāk, datu pieejamības izlases un ZK-EVM kombinācija nozīmē, ka iespējamā Ethereum mērogošanas nākotne patiesībā izskatās ļoti tuvu šim redzējumam! Savukārt, izmantojot konta abstrakciju, mēs jau no paša sākuma zinājām, ka ir iespējama sava veida ieviešana, tāpēc nekavējoties tika uzsākta izpēte, lai mēģinātu kaut ko padarīt pēc iespējas tuvāk tīram sākuma punktam "darījums ir tikai zvans".
Starp darījuma apstrādi un faktiskā pamatā esošā EVM izsaukuma veikšanu no sūtītāja adreses ir daudz standarta koda, un pēc tam ir nepieciešams vēl papildu kods. Kā samazināt šo kodu pēc iespējas tuvāk nullei?
Viens no galvenajiem kodiem šeit ir valide_transaction(state, tx), kas ir atbildīgs par pārbaudi, vai darījuma nonce un paraksts ir pareizi. Konta abstrakcijas patiesais mērķis jau no paša sākuma ir bijis ļaut lietotājiem aizstāt pamata nepakāpenisku verifikāciju un ECDSA verifikāciju ar savu verifikācijas loģiku, lai lietotāji varētu vieglāk izmantot tādas funkcijas kā sociālā atkopšana un vairāku parakstu maki. Tātad, atrast veidu, kā pārveidot application_transaction par vienkāršu EVM izsaukumu, nav tikai uzdevums "padarīt kodu tīru, lai padarītu kodu tīru", bet gan par loģikas pārvietošanu lietotāja konta kodā, sniedzot lietotājiem nepieciešamo elastību nepieciešams.
Tomēr, uzstājot, ka application_transaction ietver pēc iespējas mazāk fiksētas loģikas, radās daudz problēmu. Mēs varam apskatīt vienu no agrākajiem konta abstrakcijas priekšlikumiem — EIP-86.
Ja EIP-86 tiktu iekļauts tāds, kāds tas ir, tas samazinātu EVM sarežģītību, ievērojami palielinot citu Ethereum steka daļu sarežģītību, turklāt būtībā tas pats kods ir jāraksta citur, papildus jāievieš veselums. Jauna dīvainību klase Piemēram, viens un tas pats darījums ar vienādu jaucējvērtību var parādīties ķēdē vairākas reizes, nemaz nerunājot par vairākkārtēju nederīguma problēmu.
Vairākas nederīguma problēmas konta abstrakcijā. Viens darījums, kas iekļauts ķēdē, var padarīt nederīgus tūkstošiem citu mempool darījumu, padarot mempool lētu aizpildīšanu.
Kopš tā laika konta abstrakcija ir attīstījusies pakāpeniski. EIP-86 vēlāk kļuva par EIP-208 un visbeidzot par praktisko EIP-2938.
Tomēr EIP-2938 ir nekas cits kā minimālistisks. Tās saturs ietver:
Jauns darījuma veids
Trīs jauni darījumu apjoma globālie mainīgie
Divi jauni operācijas kodi, tostarp ļoti neveiklais PAYgas operētājsistēmu kods, lai apstrādātu gāzes cenas un gāzes ierobežojumu pārbaudes kā EVM izpildes pārtraukuma punktus un īslaicīgi saglabātu ETH vienreizējai nodevu samaksai
Sarežģīts ieguves un retranslācijas stratēģiju kopums, tostarp aizliegto operāciju kodu saraksts darījuma pārbaudes posmā
Cenšoties panākt konta abstrakciju, neiesaistot Ethereum galvenos izstrādātājus (kuri koncentrējās uz Ethereum klientu optimizēšanu un apvienošanas ieviešanu), EIP-2938 galu galā tika pārveidots par ERC-4337, kas bija pilnībā ārpus protokola.
ERC-4337. Tas pilnībā paļaujas uz EVM zvaniem!
Tā kā šī ir ERC, tai nav nepieciešama cietā dakša, un tā tehniski pastāv "ārpus Ethereum protokola". Tātad... problēma atrisināta? Izrādās, ka tā nav. Pašreizējais ERC-4337 vidusposma ceļvedis faktiski ietver lielu daļu ERC-4337 pāreju uz virkni protokola līdzekļu, kas ir noderīgs piemērs norādījumiem, kāpēc šis ceļš būtu jāņem vērā.
Iepakojums ERC-4337
Ir apspriesti vairāki galvenie iemesli, kāpēc ERC-4337 ir jāatgriežas protokolā:
Gāzes efektivitāte: jebkura darbība, kas tiek veikta EVM, rada zināmu virtuālās mašīnas izmaksu, tostarp neefektivitāti, izmantojot gāzi dārgas funkcijas, piemēram, krātuves vietas. Pašlaik šīs papildu neefektivitātes dēļ ir vismaz 20 000 gāzes, ja ne vairāk. Šo komponentu ievietošana protokolā ir vienkāršākais veids, kā novērst šīs problēmas.
Koda kļūdu risks: ja ERC-4337 "ieejas punkta līgumā" ir pietiekami briesmīga kļūda, visi ar ERC-4337 saderīgie maki var redzēt, ka visi viņu līdzekļi izsīkst. Līgumu aizstāšana ar protokola funkcionalitāti rada netiešu pienākumu labot koda kļūdas, izmantojot dakšiņas, tādējādi novēršot risku, ka lietotājiem pietrūks līdzekļu.
Atbalsta EVM operācijas kodus, piemēram, txt.origin. ERC-4337 pati par sevi liek txt.origin atgriezt "grupētāja" adresi, kas darījumā iesaiņo lietotāja darbību kopu. Vietējā konta abstrakcija atrisina šo problēmu, liekot failam txt.origin norādīt uz faktisko kontu, no kura tiek nosūtīts darījums, tādējādi liekot tam darboties tāpat kā EOA.
Izturība pret cenzūru: Viens no izaicinājumiem, kas rodas, nošķirot ierosinātāju/būvētāju, ir tas, ka kļūst vieglāk pārskatīt atsevišķus darījumus. Pasaulē, kurā Ethereum protokols var identificēt atsevišķas transakcijas, šo problēmu var ievērojami atvieglot iekļaušanas saraksti, kas ļauj ierosinātājiem norādīt darījumu sarakstu, kas ir jāiekļauj nākamajos divos laika nišos gandrīz visos gadījumos. Tomēr ERC-4337 ārpus protokola iekapsulē "lietotāja darbības" vienā darījumā, padarot lietotāja darbības nepārskatāmas Ethereum protokolam, tādēļ Ethereum protokola nodrošinātais iekļaušanas saraksts nespēs nodrošināt ERC-4337 lietotājam pretestību cenzūrai; operācijas. ERC-4337 iesaiņošana un lietotāja darbības padarīšana par "pareizu" transakcijas veidu atrisinātu šo problēmu.
Ir vērts pieminēt, ka pašreizējā formā ERC-4337 ir ievērojami dārgāks nekā "pamata" Ethereum darījumi: darījums maksā 21 000 gāzes, savukārt ERC-4337 maksā aptuveni 42 000 gāzes.
Teorētiski vajadzētu būt iespējai pielāgot EVM gāzes izmaksu sistēmu, līdz sakrīt protokola izmaksas un izmaksas par piekļuvi krātuvei ārpus protokola, nav iemesla tērēt 9000 gāzes, lai pārsūtītu ETH, kad tiek rediģēti citi krātuves veidi operācijas ir lētākas. Faktiski divi EIP, kas saistīti ar gaidāmo Verkle koka transformāciju, faktiski cenšas to darīt. Bet pat tad, ja mēs to darām, ir acīmredzams iemesls, kāpēc neatkarīgi no tā, cik efektīva kļūst EVM, iekapsulētā protokola funkcijas neizbēgami būs daudz lētākas nekā EVM kods: iekapsulētais kods nav jāmaksā par iepriekšēju ielādi.
Pilnībā funkcionāls ERC-4337 maciņš ir liels, un šī implementācija ir apkopota un ievietota ķēdē, aizņemot aptuveni 12 800 baitus. Protams, jūs varētu izvietot šo kodu vienreiz un izmantot DELEGATECALL, lai ļautu katram atsevišķam makam to izsaukt, taču jums joprojām būs jāpiekļūst kodam katrā blokā, kurā tas tiek izmantots. Saskaņā ar Verkle koka gāzes izmaksu EIP 12 800 baiti veidos 413 gabalus, un, lai piekļūtu šiem gabaliem, būs jāmaksā 2 reizes liecinieka filiāles izmaksas (kopā 3800 gāzes) un 413 reizes lielākas par liecinieka chunk_cost (kopā 82 600 gāzes). Šeit pat netiek pieminēts pats ERC-4337 ieejas punkts, kura versijā 0.6.0 ķēdē ir 23 689 baiti (aptuveni 158 700 gāzes, kas jāielādē saskaņā ar Verkle tree EIP noteikumiem).
Tas rada problēmu: gāzes izmaksas par faktisku piekļuvi šiem kodiem ir kaut kādā veidā jāamortizē visos darījumos. Pašreizējā pieeja, ko izmanto ERC-4337, nav ļoti laba: pirmais darījums komplektā patērē vienreizējās krātuves/koda lasīšanas izmaksas, padarot to daudz dārgāku nekā citi darījumi. Iekapsulēšana protokolā ļaus šīm publiskajām koplietotajām bibliotēkām kļūt par protokola daļu un brīvi pieejamām ikvienam.
Ko mēs varam mācīties no šī piemēra, un kad iekapsulēšana būtu jāpraktizē vispārīgāk?
Šajā piemērā mēs redzam dažus atšķirīgus iemeslus kontu abstrakciju iekapsulēšanai protokolos.
Uz tirgu balstītas pieejas, kas "nospiež sarežģītību līdz malai", visticamāk, neizdosies, ja fiksētās izmaksas ir augstas. Faktiski ilgtermiņa kontu abstrakcijas ceļvedim ir daudz fiksēto izmaksu par bloku. 244 100 gāzes standartizēta maka koda ielādei ir viena lieta, taču apkopošana var pievienot simtiem tūkstošu gāzes ZK-SNARK verifikācijai, kā arī ķēdē esošās pārbaudes izmaksas. Nekādā gadījumā nevar iekasēt maksu par šīm izmaksām, neradot milzīgu tirgus neefektivitāti, un, pārvēršot dažas no šīm funkcijām par protokola līdzekļiem, kuriem ikviens var piekļūt bez maksas, šī problēma tiktu atrisināta ļoti labi.
Kopienas mēroga reakcija uz koda kļūdām. Ja kādu koda daļu izmanto visi lietotāji vai ļoti plašs lietotāju loks, blokķēdes kopienai bieži vien ir saprātīgāk uzņemties atbildību, lai novērstu visas radušās kļūdas. ERC-4337 ievieš lielu daudzumu globāli koplietota koda. Ilgtermiņā neapšaubāmi ir saprātīgāk labot kļūdas kodā, nevis likt lietotājiem zaudēt lielu daudzumu ETH.
Dažreiz spēcīgāku protokola formu var ieviest, tieši izmantojot tā funkcionalitāti. Galvenais piemērs šeit ir cenzūrai izturīgas funkcijas protokolā, piemēram, iekļautie saraksti. Protokola iekļaušanas saraksti var nodrošināt labāku pretestību cenzūrai nekā ārpusprotokola metodes, lai lietotāja līmeņa darbības gūtu patiesu labumu no protokola ietver sarakstus, atsevišķus lietotājus Līmeņa operācijām ir nepieciešama protokola "lasāmība". Vēl viens mazāk zināms piemērs ir tas, ka 2017. gada ēras Ethereum likmju pierādīšanas dizainā bija likmju atslēgu konta abstrakcija, kas tika atcelta par labu iekapsulētajam BLS, jo BLS atbalstīja "apkopošanas" mehānismu, kas bija jāievieš protokolā un tīkla līmeņos, tas var padarīt liela skaita parakstu apstrādi efektīvāku.
Taču ir svarīgi atcerēties, ka pat kontu abstrakciju iekapsulēšana protokolos joprojām ir milzīga “dekapsulēšana”, salīdzinot ar status quo. Mūsdienās augstākā līmeņa Ethereum darījumus var uzsākt tikai no ārējiem kontiem (EOA), kas tiek verificēti, izmantojot vienu secp256k1 eliptiskās līknes parakstu. Konta abstrakcija to novērš, un lietotājam ir jādefinē validācijas nosacījumi. Tāpēc šajā stāstā par kontu abstrakciju mēs redzam arī lielāko iemeslu pret iekapsulēšanu: elastība, lai apmierinātu dažādu lietotāju vajadzības.
Paplašināsim stāstu, apskatot dažus citus tādu funkciju piemērus, kuras nesen tika apsvērtas iekapsulēšanai. Īpašu uzmanību pievērsīsim: ZK-EVM, ierosinātāja un veidotāja atdalīšanai, privātajiem atmiņas fondiem, likviditātes piesaistei un jaunai priekškompilācijai.
PackageZK-EVM
Pievērsīsim uzmanību citam potenciālajam Ethereum protokola iekapsulēšanas mērķim: ZK-EVM. Pašlaik mums ir liels skaits ZK apkopojumu, kuriem visiem ir jāraksta diezgan līdzīgs kods, lai pārbaudītu līdzīgu Ethereum bloku izpildi ZK-SNARK. Pastāv diezgan daudzveidīga neatkarīgu ieviešanu ekosistēma: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth un citi.
Nesenais strīds EVM ZK apkopojuma laukā ir saistīts ar to, kā rīkoties ar kļūdām, kas var parādīties ZK kodā. Pašlaik visām šīm darba sistēmām ir sava veida "drošības padomes" mehānisms, kas kontrolē atestācijas sistēmu kļūdu gadījumā. Pagājušajā gadā es mēģināju izveidot standartizētu sistēmu, kas mudinātu projektus noskaidrot, cik ļoti viņi uzticas atestācijas sistēmai un cik ļoti viņi uzticas Drošības padomei, un laika gaitā pakāpeniski samazinātu viņu pilnvaras pār šo organizāciju.
Vidējā termiņā apkopošana var balstīties uz vairākām sertifikācijas sistēmām, un Drošības padomei būs tiesības tikai ārkārtējos gadījumos, kad atšķiras divas dažādas sertifikācijas sistēmas.
Tomēr ir sajūta, ka daži no šiem darbiem šķiet lieki. Mums jau ir Ethereum bāzes slānis, tam ir EVM, un mums jau ir darba mehānisms kļūdu novēršanai ieviešanā: ja ir kļūda, klients tiks atjaunināts, lai to novērstu, un ķēde turpinās darboties. No buggy klienta viedokļa šķiet, ka pabeigtie bloki vairs netiks apstiprināti, taču mēs vismaz neredzēsim, ka lietotāji zaudēs līdzekļus. Tāpat, ja apkopojumi vienkārši vēlas saglabāt līdzvērtīgu EVM lomu, tiem ir jāievieš sava pārvaldība, lai pastāvīgi mainītu savus iekšējos ZK-EVM noteikumus, lai tie atbilstu jauninājumiem Ethereum bāzes slānim, kas šķiet nepareizi, jo galu galā tie ir veidoti uz augšu. no paša Ethereum bāzes slāņa, tas zina, kad jaunināt un saskaņā ar kādiem jaunajiem noteikumiem.
Tā kā šie L2 ZK-EVM pamatā izmanto tieši to pašu EVM kā Ethereum, vai mēs varam kaut kādā veidā iekļaut protokola funkcionalitātē "verificēt EVM izpildi ZK" un rīkoties ar izņēmumiem, piemērojot Ethereum sociālo konsensu, piemēram, kļūdas un jauninājumus, kā mēs jau darām bāzes slānis EVM pati izpilde?
Šī ir svarīga un izaicinoša tēma.
Viens no iespējamiem debašu tematiem par datu pieejamību vietējā ZK-EVM ir statusīgums. ZK-EVM būtu daudz efektīvāki datu iegūšanai, ja tiem nebūtu jāpārvadā "liecinieku" dati. Tas ir, ja kāds konkrēts datu fragments ir nolasīts vai ierakstīts kādā iepriekšējā blokā, mēs varam vienkārši pieņemt, ka pārbaudītājam ir piekļuve tiem un viņam tas nav jādara pieejams vēlreiz. Runa nav tikai par krātuves un koda neielādēšanu, bet ir pierādīts, ka, ja apkopojums pareizi saspiež datus, statusa saspiešana var ietaupīt līdz pat 3 reizēm, salīdzinot ar bezstāvokļa saspiešanu.
Tas nozīmē, ka ZK-EVM iepriekšējai kompilācijai mums ir divas iespējas:
1. Iepriekšējai kompilācijai ir nepieciešams, lai visi dati būtu pieejami vienā blokā. Tas nozīmē, ka pārbaudītājs var būt bezvalstnieks, taču tas nozīmē arī to, ka šī iepriekš kompilētā ZK apkopojuma izmantošana ir daudz dārgāka nekā pielāgota koda apkopojuma izmantošana.
2. Iepriekšēja kompilācija ļauj rādītājiem norādīt uz datiem, kas izmantoti vai ģenerēti iepriekšējās izpildēs. Tas padara ZK apkopojumu tuvu optimālam, taču tas ir sarežģītāks un ievieš jaunu stāvokli, kas ir jāsaglabā pārbaudītājam.
Ko mēs no tā varam mācīties? Ir pamatots iemesls kaut kādā veidā iekļaut ZK-EVM verifikāciju: apkopojums jau veido savu pielāgoto versiju, un Ethereum vēlas ieviest EVM L1, ņemot vērā tās daudzo ieviešanu un ārpus ķēdes sociālo vienprātību, tas šķiet nepareizi. , bet L2, kas veic tieši to pašu darbu, būtu jāievieš sarežģīts sīkrīks, iesaistot Drošības padomi. Bet, no otras puses, ir liela problēma detaļās: ir dažādas ZK-EVM versijas, un tām ir dažādas izmaksas un ieguvumi. Atšķirība starp statusu un bezvalsts tikai saskrāpē virsmu, mēģinājumi atbalstīt "gandrīz EVM" pielāgotu kodu, kas ir pierādīts ar citām sistēmām, var atklāt lielāku dizaina telpu. Tāpēc ZK-EVM iepakošana nes gan cerību, gan izaicinājumus.
Iekapsulēšanas ierosinātāja un veidotāja atdalīšana (ePBS)
MEV pieaugums padara bloku ražošanu par liela mēroga saimniecisku darbību, kurā sarežģīti dalībnieki spēj ražot blokus, kas rada lielākus ieņēmumus nekā noklusējuma algoritms, kas vienkārši novēro darījumu kopu un tos satur. Līdz šim Ethereum kopiena ir mēģinājusi uzlabot esošo rīku pieredzi, palielinot to funkcionalitāti un padarot tos izturīgākus. BOOST ir vietējās utilītas marķieris, ko izmanto, lai atbloķētu augstākās kvalitātes un jaunināmos līdzekļus, turpmāk balsotu pārvaldības pasākumos un maksājumu apstrādi par turpmākajām produkta funkcijām. Gaidāmie BOOST produkti ietver BoostSWAP, BoostFARM un BoostNFT. Šie inovatīvie produkti uzlabos esošo DeFi infrastruktūru un palīdzēs paplašināt decentralizēto interneta kopienu. Monēta BOOST tika izlaista 2021. gada 9. augustā, un apgrozībā bija 1 miljards žetonu. Boost pašlaik var tirgot vietnē Uniswap, un drīzumā tas būs pieejams BoostSwap. Skatiet citus šīs problēmas risinājumus, piemēram, ārpus protokola ierosinātāju un veidotāju nodalīšanu, kas ļauj regulāriem pārbaudītājiem (“ieteicējiem”) uzticēt bloku būvniecību specializētiem dalībniekiem (“būvētājiem”).
Tomēr MEV-Boost izdara uzticības pieņēmumus jaunai aktieru klasei, ko sauc par relejiem. Pēdējo divu gadu laikā ir bijuši daudzi priekšlikumi izveidot "iepakotu PBS". Kādi ir ieguvumi no šīs darbības? Šajā gadījumā atbilde ir ļoti vienkārša: PBS, kas izveidots, tieši izmantojot protokola līdzekļus, ir jaudīgāks (tajā nozīmē, ka tam ir vājāki uzticamības pieņēmumi) nekā PBS, kas izveidots, tos neizmantojot. Tas ir līdzīgi kā cenu orākulu iekapsulēšanas gadījumā protokolā – lai gan šajā gadījumā ir nopietni iebildumi.
Iekapsulējiet privāto atmiņas baseinu
Kad lietotājs nosūta darījumu, tas nekavējoties ir publisks un redzams visiem, pat pirms tas ir iekļauts ķēdē. Tas padara daudzu lietojumprogrammu lietotājus neaizsargātus pret ekonomiskiem uzbrukumiem, piemēram, priekšējo darbību.
Pēdējā laikā ir bijuši vairāki projekti, kas veltīti "privāto mempool" (vai "kriptoatmiņu") izveidei, kas šifrē lietotāju darījumus, līdz tie tiek neatgriezeniski pieņemti blokā.
Tomēr problēma ir tāda, ka šādai shēmai ir nepieciešams īpašs šifrēšanas veids: lai lietotāji nepārpludinātu sistēmu un vispirms to atšifrētu, šifrēšana ir automātiski jāatšifrē pēc tam, kad darījums faktiski ir neatgriezeniski akceptēts.
Ir dažādas metodes ar dažādiem kompromisiem, lai ieviestu šo šifrēšanas veidu. Džons Šarbono reiz to labi aprakstīja:
Šifrēšana centralizētiem operatoriem, piemēram, Flashbots Flashbots Flashbots ir pētniecības un attīstības uzņēmums, kas koncentrējas uz Miner Extractable Value (MEV), kuras mērķis ir mazināt negatīvos ārējos efektus un eksistenciālos riskus, ko MEV rada viedās līgumu blokķēdes. Skatīt vairāk Aizsargāt.
Laika bloķēšanas šifrēšana. Šo šifrēšanas formu ikviens var atšifrēt pēc noteiktām secīgām aprēķina darbībām, un to nevar paralēli veikt;
Sliekšņa šifrēšana uzticas godīgai vairākuma komitejai datu atšifrēšanai. Konkrētus ieteikumus skatiet slēgto bākugunis ķēžu koncepcijā.
Uzticama aparatūra, piemēram, SGX.
Diemžēl katrai šifrēšanas metodei ir dažādi trūkumi. Lai gan katram risinājumam ir noteikts lietotāju segments, kas vēlas tam uzticēties, neviens risinājums nav pietiekami uzticams, lai tas tiktu pieņemts 1. slānī. Tāpēc vismaz līdz brīdim, kad tiek pilnveidota aizkavētā šifrēšana vai sasniegts kāds cits tehnoloģisks sasniegums, anti-ahead tirdzniecības funkcionalitātes iekapsulēšana 1. slānī šķiet sarežģīts piedāvājums, pat ja tā ir pietiekami vērtīga funkcija, ka ir radušies daudzi lietojumprogrammu risinājumi.
Iekapsulēta likviditāte
Ethereum DeFi lietotāju izplatīta vajadzība ir iespēja izmantot savu ETH gan ķīlām, gan kā nodrošinājumu citās lietojumprogrammās. Vēl viens izplatīts pieprasījums ir vienkārši ērtības labad: lietotāji vēlas, lai tie varētu veikt likmes (un aizsargāt tiešsaistes likmju atslēgas) bez sarežģītības, kas saistītas ar mezgla palaišanu un tā pastāvīgu uzturēšanu tiešsaistē.
Līdz šim vienkāršākā likmēšanas "interfeiss", kas atbilst abām šīm vajadzībām, ir tikai ERC20 marķieris: pārveidojiet savu ETH par "likmēšanas ETH", turiet to un pēc tam konvertējiet to atpakaļ. Faktiski Lido Lido Lido ir likviditātes portfeļa risinājums. Lido ļauj lietotājiem veikt likmes uz PoS publisko ķēdi ar saliktām atdevēm, vienlaikus piedaloties ķēdes darbībās (piemēram, kreditēšanā, tirdzniecībā) bez minimāliem noguldījumiem vai infrastruktūras uzturēšanas. Pašlaik tas atbalsta ETH2.0, Terra un Solana, un nākotnē tas var tikt paplašināts uz citām POS publiskajām ķēdēm. Skatīt vairāk un Rocket Rocket Rocket (ROCKET) ir kriptovalūta, kas tika izlaista 2021. gadā un darbojas BNB Smart Chain (BEP20) platformā. Skatīt vairāk Pool Pool atbalsta organizācijas, kas ļauj vienkāršiem cilvēkiem gūt peļņu un koplietot savus datus. Skatīt vairāk Likviditātes nodrošinātāji, piemēram, jau ir sākuši to darīt. Tomēr ir daži dabiski centralizācijas mehānismi, kas spēlē likviditātes ieguldījumu: cilvēki, protams, pāries uz lielāko ETH versiju, jo tā ir vispazīstamākā un likvīdākā.
Katrai piesaistītā ETH versijai ir jābūt mehānismam, lai noteiktu, kurš var kļūt par pamata mezgla operatoru. Tas nevar būt neierobežots, jo tad uzbrucēji pievienosies un izmantos lietotāju līdzekļus, lai paplašinātu savus uzbrukumus. Pašlaik divi galvenie ir Lido un Rocket Pool Rocket Pool RocketPool ir Ethereum PoS infrastruktūras pakalpojums. Visas personas un organizācijas, kas vēlas nopelnīt Ethereum procentus, veicot regulāras likmes, var piedalīties likšanā, izmantojot RocketPool decentralizēto un mezglu darbināmo tīklu. Skatīt vairāk , pirmajam ir DAO baltajā sarakstā iekļauti mezglu operatori, bet otrais ļauj ikvienam palaist mezglu ar 8 ETH depozītu. Abām metodēm ir dažādi riski: raķešu baseina metode ļauj uzbrucējam veikt 51% uzbrukumu tīklam un liek lietotājiem maksāt lielāko daļu izmaksu, tāpat kā DAO metodei, ja noteiktais marķieris kļūst dominējošs, tas novedīs vienā, potenciāli apdraudētais pārvaldības sīkrīks kontrolē lielu daļu no visiem Ethereum pārbaudītājiem. Jāsaka, ka protokoli, piemēram, Lido, ir ieviesuši drošības pasākumus, taču ar vienu aizsardzības līmeni var nepietikt.
Īstermiņā viena no iespējām ir mudināt ekosistēmu dalībniekus izmantot dažādus likviditātes nodrošinātājus, lai samazinātu iespēju, ka dominējošais spēlētājs rada sistēmisku risku. Tomēr ilgtermiņā tas ir nestabils līdzsvars, un pārmērīga paļaušanās uz morālo spiedienu problēmu risināšanā ir bīstama. Rodas dabisks jautājums: vai būtu jēga protokolā iekļaut kādu funkcionalitāti, lai likviditātes piesaiste būtu mazāk centralizēta?
Galvenais jautājums šeit ir: kāda veida protokola funkcionalitāte? Viena problēma, vienkārši izveidojot aizstājamu ETH marķieri protokola ietvaros, ir tāda, ka tai ir jābūt iekapsulētai Ethereum mēroga pārvaldībai, lai izvēlētos, kurš vadīs mezglus, vai arī tam jābūt atvērtam, bet tas pārvērstu to par Uzbrucēja rīki.
Interesanta ideja ir Dankrada Feista raksts par likviditātes likmju maksimizēšanu. Pirmkārt, iekožam lodi, ja Ethereum ir pakļauts 51% uzbrukumam, var tikt zaudēti tikai 5% no uzbrukuma ETH. Tas ir saprātīgs kompromiss ar vairāk nekā 26 miljoniem ETH, uzbrukuma trešdaļai no tā (~8 miljoni ETH) izmaksas ir pārmērīgas, jo īpaši ņemot vērā to, cik daudz "nepiemērotu" uzbrukumu var veikt vienā vietā; zemākas izmaksas. Faktiski līdzīgi kompromisi ir izpētīti Superkomitejas priekšlikumā ieviest vienas slota galīgumu.
Ja mēs pieņemam, ka tiek samazināti tikai 5% no uzbrukuma ETH, tad vairāk nekā 90% no piesaistītā ETH netiks ietekmēta, tāpēc tos var izmantot kā aizstājamus šķidruma piesaistes marķierus protokolā un pēc tam izmantot citās lietojumprogrammās.
Šis ceļš ir interesants. Bet tas joprojām atstāj vienu jautājumu: kas īsti ir iekapsulēts? Rocket Pool darbojas ļoti līdzīgi: katrs mezgla operators nodrošina dažus līdzekļus, bet likviditātes piesaistītāji nodrošina pārējo. Mēs varam vienkārši pielāgot dažas konstantes, lai ierobežotu maksimālo sodu līdz 2 ETH, un Rocket Pool esošais rETH kļūs bezriska.
Ar vienkāršiem protokola pielāgojumiem mēs varam paveikt arī citas gudras lietas. Piemēram, pieņemsim, ka mēs vēlamies sistēmu ar diviem ieguldījuma "līmeņiem": mezglu operatori (augstas nodrošinājuma prasības) un noguldītāji (nav minimālo nodrošinājuma prasību, var pievienoties un izstāties jebkurā laikā), taču mēs joprojām vēlamies piešķirt nejauši atlasītu noguldītāju komitejas pilnvaras, lai novērstu mezglu operatoru centralizāciju, piemēram, ieteiktu darījumu sarakstu, kas jāiekļauj (izturības cenzūras dēļ), kontrolētu dakšu atlasi neaktivitātes noplūdes laikā vai pieprasot parakstus uz blokiem. To var paveikt tādā veidā, kas būtībā neatbilst protokolam, pielāgojot protokolu, lai katram pārbaudītājam būtu jānodrošina (i) regulāra likmes atslēga un (ii) ETH adrese, ko var izmantot katrā slotā, tiek izsaukta, lai izvadītu sekundārā ķīlas atslēga. Protokols dotu pilnvaras abām atslēgām, bet otrās atslēgas izvēles mehānismu katrā slotā varētu atstāt staking pool protokola ziņā. Tomēr var būt labāk iekapsulēt dažas funkcionalitātes tieši, taču ir vērts atzīmēt, ka šāda dizaina telpa "iekļaut dažas lietas un atstāt citas lietas lietotāja ziņā" pastāv.
Iekapsulējiet vairāk priekškompilācijas
Iepriekš kompilētie (jeb "iepriekš kompilētie līgumi") ir Ethereum līgumi, kas īsteno sarežģītas kriptogrāfijas darbības ar loģiku, kas sākotnēji tiek ieviesta klienta kodā, nevis EVM viedā līguma kodā. Iepriekšēja kodēšana ir kompromiss, kas pieņemts no Ethereum izstrādes sākuma: tā kā virtuālās mašīnas izmaksas ir pārāk lielas ļoti sarežģītam un ļoti specializētam kodam, mēs varam ieviest dažas svarīgas lietojumprogrammas vietējā kodā, lai padarītu tās ātrākas. Mūsdienās tas būtībā ietver dažas īpašas jaucējfunkcijas un eliptiskās līknes darbības.
Pašlaik tiek mēģināts pievienot secp256r1 priekškompilāciju, kas ir nedaudz atšķirīga eliptiskā līkne nekā secp256k1, ko izmanto pamata Ethereum kontiem, jo to labi atbalsta uzticami aparatūras moduļi, tāpēc tā plaša izmantošana varētu uzlabot seifa drošību. Pēdējos gados kopiena ir arī centusies pievienot iepriekšēju kompilāciju BLS-12-377, BW6-761, vispārēju savienošanu pārī un citas funkcijas.
Pretarguments šiem aicinājumiem izveidot vairāk priekškompilatoru ir tas, ka daudzi iepriekš pievienotie priekškompilatori (piemēram, RIPEMD un BLAKE) tika izmantoti daudz retāk, nekā paredzēts, un mums no tā būtu jāmācās. Tā vietā, lai pievienotu vairāk priekškompilācijas konkrētām darbībām, mums, iespējams, vajadzētu koncentrēties uz pieticīgāku pieeju, kuras pamatā ir EVM — MAX MAX MAX Token ir Max Asset Exchange (MAX) utilīta marķieris. MAX Exchange koncentrējas uz savas tirdzniecības kopienas atbalstīšanu un visdrošākās tirdzniecības platformas nodrošināšanu. MAX Tokens tiks apbalvoti, izmantojot darījumu ieguvi, un tos var izmantot arī platformas likmēm, lai iegūtu atlīdzību. Skatīt vairāk un tādas idejas kā neaktivizētais, bet vienmēr atsāktais SIMD priekšlikums, kas ļautu EVM implementācijām izpildīt plašu kodu klašu klāstu par zemākām izmaksām. Varbūt pat esošo mazlietoto priekškompilāciju varētu noņemt un aizstāt ar (neizbēgami mazāk efektīvu) tādu pašu funkciju EVM koda ieviešanu. Tomēr joprojām ir iespējams, ka ir noteiktas kriptogrāfijas darbības, kas ir pietiekami vērtīgas, lai paātrinātu, tāpēc ir lietderīgi tās pievienot kā iepriekš kompilētas.
Ko mēs no tā visa esam mācījušies?
Vēlme iekapsulēt pēc iespējas mazāk ir saprotama un laba, tā izriet no Unix Unix View More filozofiskās tradīcijas radīt minimālistisku programmatūru, kas var viegli pielāgoties dažādām lietotāju vajadzībām un izvairīties no programmatūras uzpūšanās. Tomēr blokķēde nav personālo datoru operētājsistēma, bet gan sociālā sistēma. Tas nozīmē, ka ir lietderīgi protokolā iekļaut noteiktu funkcionalitāti.
Daudzos gadījumos šie citi piemēri ir līdzīgi tiem, ko mēs redzējām konta abstrakcijā. Bet mēs arī guvām dažas jaunas mācības:
Funkcionalitātes iekapsulēšana var palīdzēt izvairīties no centralizācijas riskiem citās steka daļās:
Bieži vien, saglabājot minimālu un vienkāršu pamata protokolu, sarežģītība tiek izstumta uz kādu ekosistēmu ārpus protokola. No Unix filozofijas viedokļa tas ir labi. Tomēr dažkārt pastāv risks, ka ārpusprotokola ekosistēma kļūs centralizēta, parasti (bet ne tikai) augsto fiksēto izmaksu dēļ. Iekapsulēšana dažkārt var samazināt de facto centralizāciju.
Pārāk daudz iekapsulēšanas var pārmērīgi palielināt protokola uzticēšanos un pārvaldības slogu:
Tas ir iepriekšējā rakstā par tēmu "Nepārslogojiet Ethereum vienprātību": ja konkrētas funkcijas iekapsulēšana vājina uzticības modeli un padara Ethereum kopumā "subjektīvāku", tas vājina Ethereum uzticamo neitralitāti. Šādos gadījumos ir labāk, ja konkrētā funkcionalitāte ir Ethereum virspusē esošais mehānisms, nevis mēģināt to ievietot pašā Ethereum. Šifrētie atmiņas pūli ir labākais piemērs šeit, ko var būt nedaudz grūti iekapsulēt, vismaz līdz latentuma šifrēšanas uzlabošanai.
Pārāk daudz iekapsulēšanas var padarīt protokolu pārāk sarežģītu:
Protokola sarežģītība ir sistēmisks risks, ko palielina, pievienojot protokolam pārāk daudz līdzekļu. Priekškompilācija ir labākais piemērs.
Iekapsulēšanas funkcionalitāte ilgtermiņā var būt neproduktīva, jo lietotāju vajadzības ir neparedzamas:
Funkcija, ko daudzi cilvēki uzskata par svarīgu un ko izmantos daudzi lietotāji, visticamāk, praksē netiek izmantota pārāk bieži.
Turklāt likviditātes ieguldījums, ZK-EVM un iepriekš apkopoti piemēri parāda vidusceļa iespējamību: minimālu dzīvotspējīgu nodrošinājumu. Protokolam nav jāiekapsulē visa funkcionalitāte, bet tajā var būt noteiktas daļas, kas risina galvenās problēmas, padarot funkcionalitāti viegli ieviešamu, nebūdams pārāk paranoisks vai pārāk šaurs. Piemēri:
Tā vietā, lai iekapsulētu pilnīgu likviditātes ieguldīšanas sistēmu, labāk ir mainīt sodu noteikumus par likmēm, lai padarītu neuzticamu likviditātes ieguldījumu veikšanu iespējamāku;
Tā vietā, lai iekapsulētu vairāk priekškompilatoru, labāk ir iekapsulēt EVM-MAX un/vai SIMD, lai būtu vieglāk efektīvi īstenot plašāku darbību klasi;
Tā vietā, lai iekapsulētu visu apkopojuma koncepciju, ir iespējams vienkārši iekapsulēt EVM verifikāciju.
Iepriekšējo diagrammu varam paplašināt šādi:
Dažreiz ir jēga kaut ko iekapsulēt, un viens piemērs ir reti izmantoto priekškompilatoru noņemšana. Kā minēts iepriekš, konta abstrakcija kopumā ir arī svarīgs dekapsulēšanas veids. Ja mēs vēlamies atbalstīt atpakaļejošu saderību esošajiem lietotājiem, mehānisms patiesībā varētu būt pārsteidzoši līdzīgs tam, kas atcēla iepriekšēju kompilāciju: viens no priekšlikumiem ir EIP-5003, kas ļautu EOA pārveidot savus kontus, lai tiem būtu tādi paši (vai labāk) funkcionāls līgums.
Kuras funkcijas jāiekļauj protokolā un kuras jāatstāj citiem ekosistēmas slāņiem, ir sarežģīts kompromiss. Paredzams, ka šis kompromiss laika gaitā turpinās uzlaboties, jo mūsu izpratne par lietotāju vajadzībām un pieejamais ideju un tehnoloģiju komplekts turpina uzlaboties.
