Nola egin Gurutze-kate tokenak berriro fungigarriak: I. zatia

Sarrera Maxis modularrek esaten dute kriptografiaren etorkizuna milioi bat (edo gehiago) interkonektatutako domeinu eta erabiltzaileek blokeo kateen artean salto egiten dutela Alice Wonderland zehar dabilen bezala. Zergatik geratu kate batekin puntako teknologia, aplikazio berrietara, staking/likiditate horniduraren ilargiaren etekinak, errendimendu handiko eta transakzio kuota oso baxuak beste bloke-kate batzuetan sar zaitezke? Baina bloke-kateen artean mugitzea Alicek Lurralde Miresgarrian zehar egindako bidaia baino askoz zailagoa da, batez ere bloke-kateen arteko elkarreragingarritasunaren egungo planteamenduek (adibidez, kate gurutzatuen zubiak) berezko dituzten mugengatik. Bereziki, gaur egun kate gurutzatuko zubiak seguruak ez dira (2,5 milioi dolar baino gehiago galdu dira zubi-hacketan), motelak, garestiak edo funtzionalitate mugatuak edo zerrendako propietateen nahasketa erakusten dute. Zubigintzaren industria pairatzen duten beste gai batzuk sotilagoak dira, baina nahikoak dira maxi modularraren ametsa kate anitzeko ekosistema baten ametsa erabiltzaile eta garatzaileentzat amesgaizto bihurtzeko; horren adibide da token fungigarriak (ERC-20ak bezalakoak) ez-fungigarriak bihurtzen diren. kate ezberdinetara zubia gurutzatu diren hainbat protokoloren bidez, beraz, bere ezaugarriak kaltetu ditu aktibo transferigarri gisa. Artikulu honetan, token-en fungigarritasuna kateetan zehar gorde nahi duen irtenbide bat aztertuko dugu token baten jatorri-kontratua dagoen edozein dela ere: ERC-7281: Sovereign-Bridged Tokens. ERC-7281-k ERC-20 hedatzen du —Ethereum-en token fungigarriak sortzeko de facto estandarra— ERC-20 token irudikapen kanonikoak urrutiko domeinuetan token jaulkitzaileek onartutako zubi anitzen bidez sortu eta erretzea ahalbidetzeko. Honek bermatzen du ERC-20 token bat zubitzen duten erabiltzaileek tokenaren bertsio fungigarriak jasoko dituztela helmugan (hau da, bi token trukatu daitezke 1:1), nahiz eta tokenak bide/zubi ezberdinen bidez zeharka bidaltzen diren. Garrantzitsua da ERC-7281 hartzen duten protokoloek zubi-tokenen kontrola mantentzen dutela (zubiak zubi-token bat kontrolatzen duen egoera ez bezala) eta zubiaren hutsegitearen kasuan esposizioa murrizteko tasa-muga muga dezakete. Erabil dezagun USDC kate ezberdinetan teorian ERC-20 token berdinen artean fungigarritasunaren adibide gisa. , hala nola Arbitrum, Base, Optimism, ohikoa da zubi kanonikoa erabiltzea Ethereum L1etik kate hauetara ERC-20 token ezagunak eramateko. L1 jatorriko L2 token bertsio hauek normalean "zubia [sartu token izena]" deitzen zaie. Ethereum Layer 2 (L2) sareetan USDC-ren kasuan, ohiko sinboloak USDC.e, USDC.b eta abar dira. Denborarekin, Circle-k bere USDC inplementazioak beste kate batzuetara hedatzen ditu, L2etara barne, non USDC dagoeneko bizi den zubi kanonikoaren bidez. Nahiz eta bi token hauek entitate berak egin eta prezio berdina izan, teknikoki desberdinak dira, token infungiezinak, beraz, ez dira "elkarreragingarriak" - USDC jatorrizko Circle-ren CCTP zubiaren bidez zubi daitekeen bitartean, USDC zubia soilik izan daiteke. zubi kanonikoaren bidez L1era itzuli da. ERC-7281-k hau konpontzen du ERC-20 luzapena sartuz, non tokenaren inplementatzaileek zubi-iturri desberdinak esleitu eta parametriza ditzaketen. Goiko adibidean, Circle-k USDC token unibertsala inplementa dezake L2 guztietan, non zubi kanonikoak (adibidez, Circle Mint, Circle CCTP eta onartutako beste zubi batzuk) tokenak beren logikaren arabera egiteko gai diren esleitzen diren. Minters hackeatzeko arriskuak minimizatzeko, hedatzaileak mugatu dezake mintegi bakoitzak zenbat token egin eta erre ditzakeen denbora-tarte zehatzean, zubi fidagarriagoak, L2 kanonikoa adibidez, muga handiagoak dituztenak eta adostasun zentralizatua duten zubiak. behekoak. ERC-7281 kate zeharkako token fungigarriak sortzeko lehen saiakera ez den arren, aurreko proposamenekin lotutako arazoak konpontzen ditu, hala nola, saltzaileen blokeoa, token jaulkitzaileen subiranotasun galera, zubidun tokenentzako likidezia abiaraztearen kostu handiak, azpiegiturak. goitik, eta zubi-matxurekiko esposizioa areagotu. Bi zatiko txosten honek subirano-zubi-token estandarra ezartzearen arrazoia aztertuko du eta ERC-7281 (xERC-20 izenez ere ezaguna) zehaztapenaren ikuspegi orokorra eskainiko du. Ethereum ekosistemako erabiltzaile, garatzaile, azpiegitura hornitzaile eta beste eragile batzuentzat ERC-7281 ezartzearen onura positiboak eta eragozpen potentzialak ere eztabaidatuko ditugu. Blockchain zubietan berritze bat Zubi-token ez-fungigarrien arazoan murgildu aurretik, lehenik eta behin zubi-token zergatik dauden ulertzen laguntzen du. Horrek, aldi berean, blockchain zubien motibazioa eta funtzionamendua ulertzea eskatzen du, zubi-operadoreak baitira zubi-token bertsioak sortzeaz arduratzen direnak. . Diru-informazio hutsez gain, zubiek beste kate batzuei buruzko informazio baliagarri bat pasa dezakete, hala nola token-tasak eta kontratu adimendunen egoera. Hala ere, aktiboak (tokens) kate batetik bestera transferitzea da gaur egun zubi batekin elkarreragiten duten erabiltzaileen erabilera kasurik ohikoena. Zubia bloke-kateen artean informazioa transferitzeko mekanismo bat da Kate arteko aktiboen transferentziak errazteko planteamenduak desberdinak dira, baina token zubi-fluxuek normalean maila altuko hiru ereduetako bat jarraitzen dute: Sarraila eta menta zubiak Erabiltzaile batek token bat bere jatorrizko edo "etxeko" katetik (hasieran jaulki zenean) beste kate batera pasa nahi du. Bi bloke-kateak ez dira elkarreragingarriak, kate bakoitzak arkitektura eta protokolo-diseinu desberdinak inplementatzen baititu, eta horrek erabiltzaileari tokenak zuzenean transferitzea eragozten du A kateko zorro-helbidetik B kateko zorro-helbide batera. Zubi-operadoreak erabiltzaileak jatorri-katean gordetako tokenak kontratu adimendun batean gordetzen ditu eta jatorrizko tokenaren irudikapen "bilduta" sortzen du xede-katean zabaldutako token-kontratu baten bidez. Erabiltzaileak alderantzizko noranzkoan zubi egin nahi duenean (helmuga-katea → jatorri-katea), bildutako tokenak helmuga-kateko zubira itzultzen ditu, eta honek zubiko logikaren arabera egiaztatzen du (adibidez, ZK frogak edo kanpoko quorum bat) eta jatorrizko tokenak askatzen ditu etxeko katean fidantzatik. Erre eta menta zubiak Fitxategian tokenak blokeatu beharrean, ikuspegi honek iturri-kateko tokenak erre (suntsitu) ditu; Ondoren, zubiak zenbateko baliokide bat egiten du helmuga-katean; Alderantzizko bidaiarako, zubi-tokenak helmuga-katean erretzen dira iturri-katean token berriak sortu aurretik; Horrek token hornikuntza osoa mantentzen du kate gurutzatuen transferentziak ahalbidetzen dituen bitartean. Truke atomikoak Ikuspegi honek iturburu-kateko aktiboak zuzenean trukatzen ditu helmuga-kateko aktiboak beste alderdi batekin. Truke atomikoak desblokeatzeko balio sekretu bereko funtsen bidez funtzionatzen dute elkarren artean blokeatzeko, hau da, edozein aldetan sekretua agerian egon bada, bestean ere agerian egon daitekeela. Honek trukeei atomitatearen propietatea ematen die. Atomizitateak esan nahi du trukea guztiz (bi aldeetatik) edo batere ez dela betetzen, iruzurra edo transferentzia partzialak edo huts eginak saihestuz. Lehen hurbilketa (lock and mint) da gaur egun ohikoena. Token natibo baten eta zubi batek egindako irudikapen bilgarriaren arteko balio-baliokidetasuna da erabiltzaileei aktiboak kate gurutzatuta "transferitu" eta hasiera batean jaulki zen tokitik bereizitako token bat erabiltzea ahalbidetzen duena. Hala ere, diseinu berriak —asmoetan oinarritutako zubiak adibidez— nahiko ezagunak bihurtu dira. "Asmoak" erabiltzaileei transakzioetarako nahi diren emaitzak adierazteko aukera ematen die ("trukatu 100 USDC 100 DAIren truke"), emaitzak lortzeko urrats zehatzak zehaztu beharrean. Asmoak UX desblokeatzeko indartsu gisa sortu dira, jendearentzat onchain-eko esperientzia asko errazten baitute eta kriptografia erabiltzeko errazago egiten baitute, batez ere konbinatuta. kateen abstrakzio-soluzioekin erabiltzaileei tokenak kateen artean transferitzeko aukera ematen diete, zubiaren azpiko konplexutasunaz kezkatu gabe. Asmoetan oinarritutako zubietan, erabiltzaileek funtsak iturburu-katean sartzen dituzte eta helmuga-katean nahi duten emaitza zehazten dute ("asmoa"). "Fillers" edo "solvers" izeneko operadore espezializatuek asmo hori bete dezakete aldez aurretik eskatutako tokenak erabiltzaileari helmuga-katean bidaliz. Ondoren, operadoreek transferentzia gertatu zela frogatzen dute iturri-katean blokeatutako fondoak itzulketa gisa eskatzeko. Zeharkako asmoek Asmoetan oinarritutako zubi batzuek blokeo eta menta mekanismoak erabiltzen dituzte kanpaiaren azpian. Kasu honetan, zubiak erabiltzailearen asmoa bete duen betegarrira bidaltzen diren token bilduta daude, edo zuzenean erabiltzaileari, betegarririk sartzen ez bada. Asmoetan oinarritutako zubiek eraginkortasun geruza gehigarri bat gehitzen dute ebazteko sarearen bidez, baina oraindik ere funtsean sarraila eta menta zubi tradizionalen printzipio berdinetan oinarritzen dira. Bildutako token bakoitza, zubi tradizionalen bidez edo intentzion oinarritutako zubiaren bidez sortua dela, zubi-operadorearen IOU gisa, fidantza-kontratutik azpiko tokenaren kopuru bat askatuko duela agintzen duena. Bilatutako aktibo horien balioa zuzenean erlazionatuta dago zubi-operadorearen (hautemandako) ahalmenarekin tokenaren etxeko katean gordetako jatorrizko tokenak kentzeko titularren eskaerak prozesatzeko. Iturburu-katean azpiko tokenak blokeatzeko eta helmuga-katean bildutako irudikapenak mintzeko baimena duen zubiak tokenaren guztizko hornikuntza konstante mantentzen dela ziurtatzen du. Azpiko tokenaren unitate baterako, dagokion bildutako tokenaren unitate bat zehatz-mehatz egiten da, eta alderantziz. Aplikazio batek bildutako token bat truke-bide gisa onartzen badu edo bildutako aktiboak moneta gisa erabiltzen baditu, aplikazioaren garatzaileek eta erabiltzaileek zubi-hornitzailearengan konfiantza dute bildutako tokena babesten duten aktibo "benetakoak" ziurtatzeko. Zergatik behar ditugu zubiak? Urrutiko kate bateko aktibo baten bertsio sintetiko batekin negoziatzeko gaitasuna —aktiboen irudikapenak sortzen dituzten zubiek gaituta— funtzio indartsua da eta garatzaileei eta erabiltzaileei kate arteko elkarreragingarritasunaren onurak erabiltzeko aukera ematen die. Abantaila horietako batzuk likidezia gehiagorako sarbidea, erabiltzaile berriekiko esposizioa eta erabiltzaileentzako malgutasuna (marruskadurarik gabe kate ezberdinetako aplikazio gogokoekin elkarreragin dezakete). Praktikan nola funtzionatzen duen hobeto ulertzeko eta garatzaileentzat zein erabiltzaileentzat zergatik den garrantzitsua, azter dezagun BobDEX izeneko fikziozko truke deszentralizatua erabiliz adibide konkretu bat. Adibide honek bildutako tokenek kate gurutzatuaren hedapena nola ahalbidetzen duten erakutsiko du, sor daitezkeen onurak eta konplikazio potentzialak nabarmenduz: BobDEX Bob-ek Ethereum-en sortu zuen Automated Market Maker (AMM) truke bat da, aktibo ezberdinen artean konfiantzarik gabeko trukeak ahalbidetzeko. BobDEX-ek jatorrizko token bat du, $BOB, gobernantza-token eta LP sari-token gisa bikoizten duena. Azken kasu honetan, BobDEX-ek BOB tokenak igortzen dizkie likidezia-hornitzaileei (LP), eta, ondorioz, igerileku bati likidezia hornitzen duten erabiltzaileek DEX-eko erabiltzaileek ordaintzen dituzten kuoten ehuneko bat jasotzeko eskubidea ematen die igerilekuan gordailatutako aktiboak trukatzeko. BobDEX-en merkatu-kuota nabarmen hazi da, baina Ethereum L1-en mugek hazkunde gehiago oztopatzen dute. Esate baterako, erabiltzaile batzuek ez dute BobDEX erabili nahi Ethereum-en, gas-tasak eta transakzio-atzerapenak direla eta; era berean, beste erabiltzaile batzuek $BOB token prezioa jasan nahi dute Ethereum-en jatorrizko $BOB token eduki beharrik gabe. Arazoa konpontzeko, Bob-ek BobDEX-en bertsio bat zabaltzen du Arbitrum-en (kuota baxua eta errendimendu handiko Layer 2 (L2) rollup) eta BOB token (wBOB) bertsio bildua zabaltzen du L2-n Arbitrum-Ethereum zubiaren bidez. BobDEX Arbitrum-en BobDEX-en Ethereum-en berdina da, wBOB erabiltzen duela izan ezik, ez jatorrizko BOB tokenak, LP sarietarako eta gobernatzeko. Aplikazio-token desberdintasunak (BOB bilduta eta BOB natiboa) ez du aldaketarik eragiten erabiltzaileen (adibidez, likidezia-hornitzaileak) BobDEX-ekin Arbitrum-en elkarreraginaren ikuspegitik. wBOB tokenak Arbitrum-Ethereum zubian dauden benetako BOB tokenen babesa denez, wBOB token jabeek Ethereum-en BOB ERC-20 token jatorrizkoak erraz trukatu ditzakete zubi-kontratuarekin elkarreraginean. Bob eta erabiltzaileentzat irabazteko modukoa da egoera: Bob-ek erabiltzaile gehiago erakar ditzake, batez ere BobDEX-en negoziatzen ari direnean, gas-kuota baxuak eta transakzio-berrespen azkarrak nahi dituzten erabiltzaileak LPek BobDEX-i likidezia hornitzetik sariak lor ditzakete Ethereum-en gas-kostu handiei eta berrespen-epe luzeei aurre egin gabe. Hodler-ek wBOB tokenak eros ditzakete merkatuan BOB tokenen prezioen aldaketetatik etekina ateratzeko, BOB ERC-20 kontratuarekin Ethereum-en elkarreragin gabe. Zubigintzaren onurak berrikuntza konposagarria hobetzera eta zubi-token baten likidezia aprobetxatzen duten erabilera-kasu berriak desblokeatzera ere zabaltzen dira. Esate baterako, Alicek AliceLend izeneko mailegu-protokolo bat sor dezake Arbitrum-en, wBOB mailegu-hartzaileen berme gisa onartzen duena, wBOB-en erabilgarritasuna zabaltzeko eta merkatu berri bat sortzeko. mailegu eta mailegurako AliceLend-i likidezia hornitzen duten mailegu-emaileek ziur daude gordailuak jasoko dituztela: erabiltzaile batek mailegu bat lehenetsi egiten badu, AliceLend-ek automatikoki enkantean jartzen ditu berme gisa gordailatutako wBOB tokenak mailegu-emaileei itzultzeko. Kasu honetan, likidatutako wBOB bermeen erosleek LP-en rola hartzen dute BobDEX-en eta wBOB tokenak 1:1 jatorrizko BOB tokenengatik trukatu daitezkeen berme bera dute. Zeharkako kate-zubiak gaur egungo forman soluzio bideragarria eman du bermatzeko eta aplikazio berriak errazteko (adibidez, kate gurutzatuen maileguak eta kate gurutzatuak DEXak). Baina gaur egun zubi-ekosistema hazkunde gehiago oztopatzen duten mugekin ari da, hala nola, kate gurutzatuaren token ez-fungigarritasuna; arazo hau zehatz-mehatz aztertuko dugu gero. Ethereum L2-en arteko (aurretik silatuta) elkarreragingarritasuna Zergatik bihurtzen dira zubi-tokenak ez fungigarriak? Aurretik deskribatutako blokeoa eta mint zubi-fluxuak paperean sinplea dirudi, baina, egia esan, ingeniaritza eta mekanismoen diseinu-ahalegin handia behar du behar bezala funtzionatzeko: zubi-token baten bertsio bilduak iturburu-katean blokeatuta dauden jatorrizko tokenekin babesten direla ziurtatzea da. Erasotzaile batek urruneko kate batean token baten irudikapenak egiten baditu iturburu-katean jatorrizko tokenak jarri gabe, zubia kaudimengabe bihur dezake (iruzurrez egindakoak) bildutako tokenak etxeko katean jatorrizko tokenekin trukatuz eta erabiltzaile legitimoek saihestuz. zubi-kontratua bildutako tokenak asmatu aurretik - gordailuak erretiratzeko. Lehenengo erronka ñabarduratsuagoa da eta zubi-token izaeratik dator: zubi-hornitzaileek urruneko kate berean egindako token baten bi irudikapen ezin dira 1:1 beste batekin trukatu. Bide ezberdinetan zehar zubitutako tokenak trukatzen saiatzen diren bi erabiltzaileren beste adibide bat erabil dezakegu, tokenak kateetan zehar mugitzearekin lotutako arazoaren alderdi hau ilustratzeko: Bigarren erronka Alice-k USDC-tik Ethereum-etik Arbitrumera zubitzen du Arbitrum zubi kanonikoaren bidez eta 200 USDC.e jasotzen ditu Arbitrum-en, Bob-ek USDC-ra Arbitrumera zubitzen du Axelar bidez eta 200 axlUSDC jasotzen du Arbitrum-en. Alicek eta Bob-ek akordio bat egiten dute Alicek 200 USDC Bob-i bidal ditzan (200 USDTren truke), Bob-ek 400 USDC Ethereum-era atera ditzan. Bob axlUSDC bidez 400 USDC erretiratzen saiatzen da eta 200 USDC baino ez ditu jasotzen, zubiak Bob-ek eman diezazkiokeen 200 USDC baino ez dituela azaltzen duen mezu batekin batera. Bob nahastuta dago bildutako ERC-20 tokenak "fungigarriak" direla eta ez lukete inori ERC-20 tokenak 1:1 trukatzea eragozten duten desberdintasunik erakutsi behar edozein aplikaziotan. Bob-ek kate gurutzatuaren zubiari buruzko ikasgai gogor bat ikasten du: "ERC-20 token fungigarria" ez du beti esan nahi "token hau 1:1 truka dezakezunik aplikazioetan zehar". Bob-ek Alicerekin negozio arriskutsuak egiteko egin duen saiakera —arriskutsua izan daiteke Alicek tokenak itzuli ezin dituelako— izugarri oker doa. Zergatik ezin ditu Bob-ek 400 USDC erretiratu berak eta Alicek helmuga-katean azpiko aktibo beraren bertsio bilduak jaso baditu? Gogoratuko duzu kate ezberdinetan jaulkitako tokenak bateraezinak direla aipatu genuela, beraz, kate ez-natibo batean jaulkitako token natibo baten irudikapena zubiaren IOU bat da, jatorrizko token kopuru bat itzultzea agintzen duena (zenbataren arabera). geratzen da) erabiltzaileak tokenaren jatorrizko katera zubi egin nahi duenean. Honenbestez, zubi-token bakoitzaren balioa etxeko katean gordailuak edukitzeaz eta helmugako katean irudikapenak egiteaz arduratzen den zubi-hornitzaileari lotuta dago; Bob-en zubi-hornitzaileak Bob-i 200 USDC bakarrik ordaindu ditzake, hori baita bere gordailutik estaltzeko funtsak dituen zenbatekoa; Alice-ren 200 USDC ezin da erretiratu Bob-en zubi-hornitzailearen bidez, inoiz ez baitzion gordailua jaso edo Aliceri IOU bat igorri. Alicek blokeatutako USDC kendu behar du Ethereum-eko Arbitrum-etik eta Bob-en zubi-hornitzailetik igaro behar du Bobek gainerako tokenetara sartu aurretik. Bob eta Aliceren dilemak zubi-hornitzaile lehiakideek azpiko aktibo baten irudikapen ez-fungigarriak anitz egiten dituzten domeinuen arteko zubiaren arazoa adierazten du. Aktibo bereko ERC-20 irudikapen ezberdinekin beste arazo bat ezin direla likidezia-bilduma bakar batean negoziatu da. Aurreko adibidea erabiliz, katean axlUSDC eta USDC.e baditugu eta horiek ETH-n eta alderantziz aldatu nahi baditugu, bi likidezia multzo zabaldu behar ditugu: ETH/axlUSDC eta ETH/USDC.e. Horrek "likiditatearen zatiketa" deritzon arazoa dakar; negoziazio-taldeek bestela izan dezaketen baino likidezia txikiagoa duten egoera bat da, funtsean merkataritza-bikote berari egokitzen zaizkion multzo anitz daudelako. Irtenbidea token baten bertsio "kanoniko" bakarra izatea da helmuga-katean zirkulatzen duena, Bob eta Alice-k tokenak trukatu ditzaten, pertsona bakoitza iturburu-kateko zubitik atera gabe. Kate bakoitzeko token kanonikoa izateak garatzaileei ere mesede egiten die, erabiltzaileak ekosistemen artean azkar mugi daitezkeelako token likideziari buruzko arazoei aurre egin gabe. Beraz, nola egingo dugu token baten bertsio kanonikoak inplementatzeko erabili eta transferitzea espero den kate bakoitzean? Hurrengo atalean, hainbat kateetan token kanonikoak sortzeko planteamendu ezagun batzuk azaltzen dira. Kate ezberdinetan token kanonikoak ezartzea Kate bakoitzeko token kanoniko bat sortzea ez da erraza, eta aukera anitz daude merkataritza eta abantaila ezberdinekin. Kate bakoitzeko token kanoniko bat sortzean, normalean token jakin baten balioa babesten duten IOUren existentziari buruz pentsatu behar dugu norekin fidatu. Demagun token baten sortzailea zarela eta kate ezberdinetan erabilgarri eta transferigarria izan nahi duzula fungigarritasunaren inguruko arazorik izan gabe; lau aukera dituzu: Atera token kanonikoak rollup/sidechain zubi kanonikoen bidez Atera token kanonikoak hirugarrenen zubi-hornitzaile baten bidez Atera token kanonikoak token-jaulkitzaileen zubi baten bidez Kate anitzeko jaulkipen zuzena truke atomikoekin Lehenengo hiru aukerak hainbat zubi-mekanismotan oinarritzen dira, tokenen kate zeharkako mugimendua errazteko. Hala ere, token-sortzaile gisa, zubia guztiz saihestea ere aukera dezakezu tokena jatorrizko kate bakoitzean igorriz. Planteamendu honen arabera, bildutako tokenetan edo zubi-azpiegituretan oinarritu beharrean, token inplementazio bereiziak baina koordinatuak mantentzen dituzu kateetan zehar, kateen arteko konfiantzarik gabeko trukea ahalbidetzen duten truke atomikoekin. Ikuspegi honek azpiegitura sofistikatuak behar ditu kateetan likidezia mantentzeko eta truke atomikoak errazteko, ordea. Jatorrizko inplementazio anitz kudeatzeko konplexutasunak ikuspegi hau baliabide tekniko handiak dituzten protokolo handietara mugatu du historikoki. 1. Atera token kanonikoak rollup/sidechain zubi kanonikoen bidez Kate batek zubi kanoniko bat badu (gamatua), jatorrizko katetik zubi egin nahi duten erabiltzaileei zure protokoloaren tokenaren irudikapenak egiteko eskubidea esleitu diezaiekezu. Katearen zubi kanonikoaren bidez bideratzen diren transakzioak (gordailuak eta erretiratzeak) normalean katearen baliozkotzaile-multzoaren bidez balioztatzen dira, eta horrek berme sendoagoak eskaintzen ditu etxeko katean gordailuek sinesgarritasunez atzera egiten dituztela irudikapen guztiak. Zubi kanonikoa token baten irudikapen kanonikoa egiten ari den arren, beste irudikapen batzuk existituko dira. Hau gertatzen da zubi kanonikoek askotan erabiltzaileei esperientzia onena eskaintzea eragozten dieten mugak dituztelako. Esate baterako, Arbitrum/Optimism-etik Ethereum-era biltzeko zubi kanonikoaren bidez zazpi eguneko atzerapena dakar, transakzioak egiaztatzaileek balioztatu behar baitituzte —eta baliteke baten bidez eztabaidatu, baliogabea bada—, bilketaren likidazio-geruza baino lehen (Ethereum-ek finkatu) transakzio sorta bat. iruzur-froga Irteera azkarragoak nahi dituzten bilketa-erabiltzaileek beste zubi-hornitzaile batzuk erabili behar dituzte, zain dauden bilketa-irteeren jabetza bere gain har dezaketen eta erabiltzailearen nahi den xede-katean likidezia aldez aurretik eskaintzeko. Horrelako zubiek lock-and-mint eredu tradizionala erabiltzen dutenean, protokolo ezberdinek jaulkitako token baten irudikapen anitz bilduta geratzen gara eta aurretik deskribatutako arazo berberei aurre egiten diegu. Balidatzaile-multzo independenteak dituzten alboko kateek latentzia txikiagoa dute, erretiratzeak alboko katearen adostasun-protokoloak erretiratzeko transakzio bat duen bloke bat berresten duenean egiten diren heinean. Polygon PoS zubia alboko kate bat domeinu ezberdinekin (Ethereum rollups eta Ethereum mainnet barne) lotzen duen zubi kanonikoaren adibidea da. Oharra: Jatorrizko Polygon PoS katera aipatzen dugu, ez likidaziorako Ethereum erabiliko duen . Poligonoa L2 bihurtuko da kanpoko baliotzaileek bermatutako alboko kate batetik Ethereum adostasunarekin bermatutako validium batera igarotzen denean. aurreikusitako validium katera Hala ere, sidechain zubiek ahultasun bat ere partekatzen dute rollup zubi kanonikoekin: erabiltzaileek konektatutako kate pare baten artean bakarrik egin dezakete zubi. Ezin dute zubi kanonikoa erabiliz beste bloke-kate batzuetara konektatu. Esate baterako, ezin duzu Arbitrum-etik Optimism-era zubi egin gaur Arbitrum zubia erabiliz edo Polygon-etik Avalanche-ra zubi Polygon PoS zubiaren bidez. 1.1. Atera token kanonikoak likidezia-zubiak erabiliz Token kanonikoak mugitzeko rollup baten jatorrizko zubian oinarritzea hainbat arazo dakartza, hala nola likidezia eskasa eta aktiboen mugimenduan atzerapenak. protokoloek arazo honen inguruan lan egiten dute likidezia-zubiekin lan eginez, erretiratze azkarrak eta latentzia baxuko zubiak errazteko*. Antolamendu honen arabera, onartutako likidezia-zubiek (a) iturburu-katean protokolo baten token baten irudiak bilduta (b) helmugan ordezkaritza kanonikorako bildutako tokenak trukatu dituzte protokoloaren jabetzako likidezia-pool baten bidez. Helmuga-katean tokenaren irudikapen kanonikoa izan ohi da sidechain/rollup zubi kanonikoak egindako bertsioa, nahiz eta salbuespenak egon (gero ikusiko dugun bezala). Adibidez, Optimism-en USDT-ren bertsio kanonikoa Optimism Bridge-k egindako opUSDT da. Likidezia-zubi bakoitzak DEX bat bezala funtzionatzen du Market Maker Automatizatuarekin (AMM) batekin likidezia multzo ezberdinetan gordailatutako aktibo bikoteen arteko trukeak egiteko. Likidezia hornidura sustatzeko, AMM igerilekuek truke-kuoten zati bat partekatzen dute igerilekuko kontratuetan token kanonikoak blokeatzen dituzten titularrek. Hau Uniswap-en ereduaren antzekoa da; desberdintasun nabarmen bakarra aktibo bikoteak izan ohi dira likidezia-zubiaren irudikapen kanonikoaren aurka token baten irudikapena. Adibidez, Hop bidez USDT Optimism-era lotzen duen erabiltzaileak hUSDT Optimism-en trukatu beharko du huSDT:opUSDT igerilekuaren bidez. Likidezia-zubi baten bidez zubi egiteko lan-fluxua honela izango da: Blokeatu jatorrizko tokenak iturburu-katean Mint bridge token jatorrizkoaren irudikapena xede-katean Trukatu zubi irudikapena irudikapen kanonikoarekin xede-katean AMM pool bidez Bidali token kanonikoak erabiltzaileari Prozesu hau antzekoa da likidezia-zubi guztietan (Across, Celer, Hop, Stargate, etab.). Hala ere, normalean azken erabiltzailearengandik urrundu ohi da —batez ere ebazteko/betegarriek— eta transakzio bakar bat bezala sentituko da zati mugikor asko izan arren. Iturburu-katera itzultzean, erabiltzaileak errepresentazio kanonikoa erretzen du edo token kanonikoa zubiaren irudikapenarekin trukatzen du AMM bidez, irudikapen hori erre eta erre-agiria eman aurretik. Behin baieztatuta, erabiltzaileak hasieran blokeatutako jatorrizko tokenak erretiratu ditzake. (Aurreko eragiketa bezala, tokenak jatorrizko katera eramateko xehetasun zikinak erabiltzaileari ezkutatuta eta konpontzaileek kudeatzen dituzte). Likidezia-zubigintza bikaina da, batez ere, rollup-en latentziaren arazoa konpontzen duelako; adibidez, Hop-ek "Bonders" izenez ezagutzen diren alderdi espezializatuei aukera ematen die erabiltzailearen erretiratzea L2-n egindako transakzioaren baliozkotasuna egiaztatzea eta rollup-aren L1 zubitik ateratzearen kostua aurre egiteko. Bonder bakoitzak L2 katerako nodo oso bat exekutatzen du eta erabiltzaile baten irteera-transakzioa azkenean L1-en berretsiko den zehaztu dezake, erabiltzaileak iruzurrezko erretiratzea abiarazteko arriskua murrizteko eta Bonderrentzat galerak eragiteko. Likidezia-zubiek ere erabiltzaileak kate gehiagoren artean mugitzeko aukera ematen dute, zubi kanonikoek ez bezala; adibidez, Hop-ek erabiltzaileei Arbitrum eta Optimism arteko zubia egiteko aukera ematen die Ethereum-era lehenbailehen erretiratu beharrik gabe. L2 → L1 zubi azkarrak bezala, L2 → L2 zubi azkarrak Bonders-ek iturburuko L2 kateko nodo osoa exekutatu behar du erretiratzeak baieztatzeko, helmugako L2 kateko erabiltzaile batentzako tokenen kostua aurre egin aurretik. Honek biltegien arteko konposagarritasun handiagoa ahalbidetzen du eta erabiltzailearen esperientzia nabarmen hobetzen du, erabiltzaileek tokenak bilketa-multzoetatik arazorik gabe mugi ditzaketelako. Baina likidezia-zubiak L2/L1 kate batean token baten errepresentazio kanonikoa egiteko kate baten zubia erabiltzearen erabilgarritasunari eragiten dioten alde txarrak ere baditu. Likidezian oinarritutako zubiaren alde txarrak eztabaidatuko ditugu hurrengo atalean: Likidezia-zubien eragozpenak 1. Irristaketa Irristapena AMM batekin elkarreraginean espero diren eta jasotako token kopuruaren aldea da. Irristapena AMM-en prezio-trukeen ondorioz gertatzen da pool bateko uneko likideziaren arabera; prezioak pareko aktibo bakoitzaren saldoaren arteko oreka mantentzen da, trukea amaitu ondoren, erabiltzaileak bat hasten duen bitartean alda daitekeena. merkataritza eta trukea gauzatzen da. Aktibo zubietarako likidezia baxuak ere areagotu dezake irristapena; multzoak ez badu nahikoa likidezia igerilekuaren alde bat berriro orekatzeko, merkataritza handi batek prezioa marjina handiz alda dezake eta erabiltzaileek trukeak prezio altuagoetan exekutatzen dituzte. Arbitrajeek aktibo bera negoziatzen duten taldeen arteko desberdintasunak zuzentzen lagunduko dutela espero da, baina baliteke merkataritza-jarduera/balio baxua duten tokenak dituzten arbitraje-lanak egiteari uko egitea. Horrek kate gurutzatutako aplikazioak eraikitzen dituzten garatzaileei ere eragiten die, irristaketak gertatzen diren ertz kasuak kontuan hartu behar baitituzte. Erabiltzaileak ezin du kate gurutzatuaren eragiketa bat osatu helmuga kate batean edo gehiagotan token kopuru txikiagoak jasotzen dituelako. Zubi-agregatzaileak bezalako aplikazioek (ezin dute jakin likidezia-zubi batek nahikoa likidezia izango duen helmuga-katean trukaketa bat irristatzerik gabe estaltzeko) arazoari aurre egiten dio gehienezko irristatze-perdoia zehaztuz eta erabiltzaileei emandako aurrekontuen berri emateko. Horrek transakzio itzulerak eragozten dituen arren, erabiltzaileek beti galtzen dute zubi-tokenaren ehunekoren bat, zubi bateko AMM multzoetako likidezia edozein dela ere. 2. Likidezia-murrizketak Likidezia-zubien oinarrizko erronka bat helmuga-katean likidezia nahikoa izateko baldintza absolutua da. Blokeatu eta mint-zubi tradizionalek ez bezala, non token-amortizazioa blokeatutako aktiboek zuzenean babesten duten, likidezia-zubiak AMM igerilekuetan dauden tokenen araberakoak dira kate gurutzatuen transferentziak osatzeko. Likidezia atalase kritikoen azpitik jaisten denean, zubi-mekanismo osoak funtzionatzeari utzi diezaioke. Zubi-eragiketak erabat geldi daitezke likidezia baxuegi jaisten bada, erabiltzaileek nahi dituzten transferentziak burutzea eragotziz; Erabiltzaileak transferentzia handiak transakzio txikiagoetan banatzera behartuta egon daitezke, igerilekuaren likidezia agortzea saihesteko; Hegazkortasun handiko edo merkatuko estresaren aldietan, likidezia-hornitzaileak multzoetatik atera daitezke, zubi-funtzionalitatea gehien behar denean; Token bikote berrien abiarazpena bereziki zaila da, hasierako likidezia garrantzitsua behar baita zubia funtzionatzeko. Likidezia-eskakizunak menpekotasun zirkularra sortzen du: zubiek likidezia handia behar dute fidagarritasunez funtzionatzeko, baina likidezia-hornitzaileak erakartzeko zubien erabilera eta kuoten sorrera koherentea frogatzea eskatzen du. Oilaskoaren eta arrautzaren arazo hau bereziki larria da token berrientzat edo gutxiagotan negoziatzen diren tokenentzat, kate anitzetan likidezia nahikoa mantentzeko zailtasunak izan ditzaketenak. 3. Okerreko pizgarriak Likidezia-zubi bat lagungarria da helmuga-kateko zubi-ordezkapenetik token kanonikorako trukeak estal ditzakeen neurrian, erabiltzaileek gehiegizko irristatzerik izan gabe; Zubiarekin elkarreraginaren gas-kostuek likidezia-zubi baten balioa ere zehazten dute erabiltzailearen ikuspegitik. Horrela, zubi-agregatzaileek eta proiektu-taldeek, token bat jaulkiz, zubiak lehenesten dituzte likidezia eta transakzio-kostuen zenbatekoaren arabera. Horrek erabiltzaileek proiektu baten tokenak zubitzea edo zubi-agregatzailea erabiltzea tokenak kate gurutzatuta bidaltzeko UX hobea izatea ziurtatzen duen arren, likidezian oinarritutako zubiak hautatzeak likidezia-hornitzaileen (LP) pizgarrietan gastatu ezin diren zubiak desabantailan jartzen ditu. Gainera, transakzio kuota hutsetan oinarritutako zubiak hautatzeak kostu operatiboak murrizteko ikuspegi zentralizatua hartzen duten eta zubi-transakzioetan kuota txikiagoak kobra ditzaketen zubien alde egiten du lehia. Bi kasuetan, zubiak ez dira, dudarik gabe, metrika garrantzitsuenean lehiatzen: segurtasuna. Likidezian oinarritutako zubiek merkataritza-jarduera baxuagoa duten buztan luzeko aktiboei ere alde egiten diete (LPak erakartzeko aukera gutxiago izan dezaten). Isats luzeko token jaulkitzaileek (edo zubi-bolumen baxuko token berriek) AMM multzoak eta abiaraztearen likidezia konfiguratu beharko dute jatorrizko token trukeak estaltzeko (likidezia-zubi baten bidez zubiak) jaulkitzailearen tokenaren irudikapen kanonikoaren aurka edo lan egin beharko dute. zubi-operadoreek LPek aktibo horren likidezia hornitzeko finantza-pizgarriak areagotzeko. 4. UX zubi eskasa Likidezia-zubiak zubi kanonikoen hobekuntza dira, baina ez daude UX arazorik gabe. Zeharkako trukeetan irristatzeaz gain, baliteke erabiltzaileek ezin izatea zubi-transakzio bat berehala burutu helmuga-katean, zubiak ez duelako nahiko likidezia helmuga-kateko token kanonikoarekin merkataritza estaltzeko. Bridges-ek ezin du jakin aktibo-bikote baterako zenbat likidezia egongo den tokenak trukatzeko erabiltzaile baten mezua helmuga-katera iristen den unean, beraz, ertz-kasu hau gehienetan saihestezina da. Erabiltzaileek bi aukera dituzte egoera honetan (biak ezegokiak): . Hau ez da optimoa zubi-transakzioetan jasandako atzerapenagatik eta erabiltzaile batek ezin duelako jakin hasieran kotizatutako token kopuru bera jasoko duen ala ez, poolen likidezia oso epe laburrean alda daitekeelako arbitrarioki. Itxaron zubiak trukea osatzeko eta token kanonikoak ateratzeko nahikoa likidezia izan arte . Hau ez da optimoa, aplikazio gehienek nahiago baitute jatorrizko token baten irudikapen kanonikoarekin integratzea (adibidez, Optimism Bridge-k egindako opUSDT) eta baliteke erabiltzailearen bildutako aktiborik ez onartzea. Jaso zubiaren jabedun token irudikapena (adibidez, hUSDT Hop Bridge-rako) 2. Atera token kanonikoak hirugarrenen zubi kanoniko baten bidez Kate anitzeko dapp batek zubi-token ez-fungigarrien arazoaren inguruan lan egin dezake zubi hautatuz, dapp-en tokenaren irudikapen kanonikoak egiteko, dapp-a zabaltzen den kate guztietan. Zubi kanonikoek proiektu baten tokenen onartutako irudikapenak asmatzearekin gertatzen den bezala, ikuspegi honek urruneko kateetan egindako tokenak proiektuaren hasierako katean zabaldutako token kontratuarekin mapatzea eskatzen du, token hornikuntza mundu osoan berdina izaten dela bermatuz. Zubi-hornitzaileak token baten akuratzea eta erretzearen jarraipena egin behar du eta akuratzeko eta erretzeko eragiketak etxeko kateko token hornikuntzarekin sinkronizatuta egotea ziurtatu behar du. bakarra Zubi-hornitzaile bakarra erabiltzeak malgutasun handiagoa eskaintzen die proiektu-taldeei, batez ere hirugarrenen zubiak ekosistema sorta zabalago baten arteko zubiak laguntzeko bultzatzen direlako gehienez kate batera konektatzen diren zubi kanonikoekin alderatuta. Aplikazio bat zabaltzen den kate guztietan zubi bat badago, erabiltzaileek azkar mugi ditzakete kate gurutzatua hasierako katera itzuli beharrik gabe; Zubi-hornitzaile batek A helmuga-katean egindako tokenak erretzen direla ziurtatu behar du erabiltzaile batek helmuga-katean tokenak eta B kateko token kanonikoak etxeko kateko tokenarekin (berriro) mapatu aurretik. Zubi-token ez fungigarrien arazoa ere ezabatzen da; erabiltzaileek zubi-hornitzaile onartuaren bidez egiten badute, beti trukatu ditzakete 1:1 beste zubi-token batzuekin. Ikuspegi honek zubi eredu kanonikoaren likidezian oinarritutako zubiaren arazoak konpontzen ditu: Erabiltzaileek ez dute labainketarik jasaten zubi-transakzioetan, zubi-hornitzaileak ez baitu bere ordezkaritza AMM baten bidez ordezkapen kanoniko baten aurka bihurtu behar; zubi-hornitzailearen tokena domeinu guztietan zubi-tokenaren irudikapen kanonikoa da. Irudikapen horien balioa zubi-hornitzaileak tokenaren jatorrizko katean blokeatutako token balioarekin lotzen da. Erabiltzaileek zubigintzan atzerapen gutxi izaten dute, zubi-hornitzaileak helmuga-katean bildutako irudikapenak mint() mezua helmugara iristen denetik berehala. Garatzaileek kate anitzeko token inplementazioak kudeatzen azpikontratatu ditzakete zubi-operadoreei AMM likidezia edo likidezia hornitzeko pizgarri programak abiarazteaz kezkatu gabe. Basatian dauden zubi-hornitzaile bakarreko tokenen adibide batzuk LayerZero-ren Omnichain Fungible Token (OFT), Axelar-en Interchain Token Service (ITS), Celer-en xAsset eta Multichain-en anyAsset. Adibide guztiak, funtsean, jabedun tokenak dira eta bateraezinak dira beste zubi-hornitzaile baten bidez bidalitako token beraren irudikapenekin. Xehetasun sotil honek zubi-tokenak kudeatzeko ikuspegi honekin arazo batzuk nabarmentzen ditu. Hain zuzen, honako hauek: Saltzaileen blokeoa Burujabetza galtzea Zubietako matxurekiko esposizio handia Xede-kateetan token-en ezaugarri pertsonalizatuak galtzea Saltzaileak onartzen dituen kateetara mugatuta egotea Nahi diren kate guztietan token helbide bera mantentzeko ezintasuna, eta horrek erabiltzailearen segurtasuna kaltetu dezake edo phishing-aren aurrean zaurgarri izan daiteke Hirugarrenen zubi kanonikoak erabiltzearen eragozpenak 1. Saltzaileen blokeoa Kate batean edo gehiagotan irudikapen kanonikoak egiteko zubi-hornitzaile bakarra hautatzeak garatzaileak saltzaileak blokeatzeko arriskua jartzen ditu. Zubi-hornitzaile bakoitzak bere azpiegiturarekin (eta ekosistema-proiektu integratuekin) bateragarria den jabedun ordezkaritza bat egiten duenez, zubi-hornitzaile bakarreko ereduak modu eraginkorrean blokeatzen du token-jaulkitzaile bat zubi-zerbitzu zehatz batera, etorkizunean beste zubi batera aldatzeko aukerarik gabe. Posible da zubi-hornitzailez aldatzea, baina aldaketa-kostuak nahikoa altuak dira proiektu gehienek bide honetatik urruntzeko. Ideia gutxiko bat emateko, demagun garatzaile batek (Bob deituko dioguna) token bat (BobToken) eman duela Ethereum-en eta LayerZero OFT aukeratzen duela BobToken-en bertsio kanonikoak egiteko Optimism, Arbitrum eta Base-n. BobToken-ek 1.000.000 token hornidura finkoa du, eta LayerZero bidez egindako zubi-tokenek zirkulazioan dauden BobTokenen hornikuntza osoaren % 50 hartzen dute. Negozio-antolaketak arin aurrera egiten du Bob-ek erabiltzaileek hobe dutela BobTokens zubi-zerbitzu lehiakide baten bidez (adibidez, Axelar) bateratzea erabaki arte. Hala ere, Bob-ek ezin du esan besterik gabe: "Axelar ITS-ra aldatzen ari naiz BobToken-en irudikapen kanonikoak egiteko Optimism, Base eta Arbitrum-en"; OFT tokenak eta ITS tokenak bateraezinak direnez, Bobek erabiltzaile zaharrentzat zein erabiltzaile berrientzat buruhausteak sortzeko arriskua du, bi BobToken potentzialki ez baitira fungigarriak (lehen azaldu dugun arazoa berriro sartuz). Gainera, LayerZero-ren BobToken-en bertsioarekin integratutako aplikazioek ezin dute Axelarren BobToken-en bertsioa ordezko gisa onartu, BobToken-en likidezia zatitzen duena BobToken-en irudikapen lehiakideak elkarrekin dauden hainbat katetan. Trantsizioa posible egiteko, Bob-ek erabiltzaileak konbentzitu behar ditu LayerZero-ren bidez egindako BobToken-en bildutako irudikapenak deskargatzeko, OFT token zubiak erre eta Ethereum-en BobTokens desblokeatzen dituen transakzio bat bidaliz. Erabiltzaileek BobToken-en irudikapen kanoniko berrira alda ditzakete Ethereum-en Axelar-ekin tokenak blokeatu eta BobToken kanonikoak jasoz (Ethereum-en token kontratuaren hornidurarekin mapatuta) helmuga-katean. Hau kostu intentsiboa da eta koordinazio eta gastu operatibo handiak eragiten ditu DAO proiektuen kudeaketa taldeentzat, beraz, aukeratutako hornitzaileari atxikitzea izan ohi da aukerarik seguruena. Hala ere, honek Bob bezalako garatzaileak posizio problematikoan uzten ditu, saltzaileen blokeoak aldatzea ezinezkoa baita zubi-hornitzaile batek akordioaren baldintzak betetzen ez baditu, funtzio multzo mugatua badu, ekosistema integrazio zabalak ez baditu, UX eskasa eskaintzen badu, etab. Zubiak ere palanka ia infinituarekin eskaintzen ditu: zubi-hornitzaileak gauza arbitrarioak egin ditzake, hala nola, tasa-muga erabiltzaileak BobTokenak zubitzea arrazoi argirik gabe, zubi-kuotak igo. edo baita zubi-eragiketak zentsuratu ere. Bob-en eskuak lotuta daude kasu honetan, hirugarrenen zubi kanoniko akastun batetik haustura garbi bat egitea negozio harremanean geratzea bezain konplexua baita. 2. Protokoloetarako subiranotasuna galtzea Saltzaileen blokeoari buruzko aurreko atalaren amaieran hirugarrenen zubi kanonikoa erabiltzearen beste arazo bat nabarmentzen da: token-jaulkitzaileek zubi-token kanonikoen kontrola trukatzen dute erosotasun handiagoaren eta UX hobekuntzaren truke. Aurreko adibidea erabiltzeko: BobToken Ethereum-en erabat Bob-en kontrolpean dago, azpian dagoen ERC-20 token-kontratua kontrolatzen baitu, baina BobToken-en Optimism, Arbitrum eta Base LayerZero-k kontrolatzen ditu, BobToken-en irudikapen kanonikoak ematen dituen OFT kontratuaren jabea. blockchain horietan. Bob-ek LayerZero-k irudikapen kanonikoak jatorrizko tokenaren jatorrizko diseinuarekin lerrokatzea espero dezakeen arren, baliteke beti horrela ez izatea. Kasurik txarrenean, BobToken-en Ethereum-en jokabidea BobToken-en Optimism-enetik nabarmen desbideratu daiteke, zubi-hornitzaileak token-kontratuaren bertsio guztiz desberdina ezartzen duelako, protokoloaren erabiltzaileentzat arazoak sortuz. Arazo hau nagusi-agente dinamikak ere areagotu dezake, non protokolo baten eta zubi-hornitzailearen helburuak eta interesak bat egiten duten. 3. Zubietako matxurekiko esposizio handia Lehenengo ikuspegian, tokenak kate bakoitzaren zubi kanonikoaren bidez zeharkatzen direnean, zubi bati eragiten dion ustiapen batek token jaulkitzailearen arriskua zubi horretan jasotzen da. Esate baterako, demagun hacker batek likidezia-zubi bat arriskuan jartzen duela eta bildutako token baten kopuru infinituak ateratzen dituela bermerik jarri gabe. Kasu horretan, likidezia multzoetan bildutako aktiborako eskuragarri dagoen gehienezko likideziara arte bakarrik atera daiteke (adibidez, cUSDT Optimism-en egin → cUSDT opUSDT kanonikoarekin aldatu → opUSDT Ethereum-era kendu zubi azkarren bidez → Ethereum-en jatorrizko USDTren truke) . Hirugarrenen zubi-eredu kanonikoan, bazkide-zubiari eragiten dion ustiapen baten ondorioz token-jaulkitzaile batek duen arriskua erasotzaileak urruneko kateetan erabiltzen duen token kopuru osoaren baliokidea da, kaltetutako zubiak hedapena duen. Hau posible da, kate guztietako irudikapen kanoniko bakoitza 1:1 trukatu daitekeelako beste kate batzuetan jaulkitako token kanonikoengatik: Demagun erasotzaile batek B katean hirugarrenen zubi bat arriskuan jartzen duela eta 1000 token (hasieran tokena A katean jaulkitzen den tokian) bermerik jarri gabe. Erasotzailearen B kateko tokenak ez daude etxeko katearen kontratuarekin mapatzen, beraz, ezin da A katetik atera. Hala ere, C katera zubi egin dezake eta 1000 B kateko token trukatu ditzake C kateko 1000 tokengatik; gogoratu, kate gurutzatu bakoitza. tokena bateragarria eta fungigarria da, zubi-zerbitzu beretik baitatoz. C kateko tokenak etxeko katearen kontratuarekin mapatzen dira, A katean (tokenaren etxeko katean) tokenak blokeatu zituzten erabiltzaileek legez egin baitzituzten, erasotzaileak C katean tokenak erretzeko eta A katean jatorrizko tokenak erretiratzeko eta potentzialki osatzeko aukera emanez. ibilbidea CEX edo fiat offramp baten bidez tokenak trukatuz. 4. Token ezaugarri pertsonalizatuak galtzea Hirugarrenen zubi kanonikoa erabiltzean, token-jaulkitzaileek sarritan galtzen dute jatorrizko inplementazioan dauden ezaugarri pertsonalizatuak edo token portaerak ezartzeko gaitasuna. Hau gertatzen da zubi-hornitzaileek jatorrizko token inplementazioan dauden funtzionalitate espezializatuak onartzen ez dituzten ERC-20 ezarpen-kontratu estandarizatuak erabili ohi dituztelako. Ohiko token ezaugarriak, hala nola, botoen delegazioa (ZK), birbasatzeko mekanismoak (stETH, USDM), transferentzia-kuota-gaitasunak (memecoins), zerrenda beltza eta zuri-zerrenda funtzioak (USDT, USDC), transferentziak eten daitezkeenak eta aktaketa arau edo baimen bereziak kendu ohi dira. tokenak hirugarrenen hornitzaile baten bidez zubitzen direnean, zubi-bertsioak normalean ERC-20 oinarrizko inplementazioa erabiliko baitu. Funtzionalitate-galera honek inkoherentziak sortzen ditu tokenak kate ezberdinetan funtzionatzen duen moduan eta ezaugarri pertsonalizatu horien araberako integrazioak hautsi ditzake. Zubi-token estandarizazioak, zubi-hornitzailearen ikuspuntutik sinpleagoa den arren, tokenaren gaitasunak murrizten ditu eraginkortasunez eta jaulkitzaileak token portaera koherentea mantentzeko bere aplikazioaren kate anitzeko ekosistema osoan zehar oztopatu dezake. Horrelako arazoek kateen arteko hedapenak amesgaizto bihur ditzakete garatzaileentzat eta oztopo bat izan dezakete kate anitzetan bizi diren aplikazioen ametsa gauzatzeko. 5. Onartutako kate mugatuak Token jaulkitzaileak aukeratutako zubi-hornitzailearen sare-estalduraren eta hedapen-planen menpe bihurtzen dira. Zubi-hornitzaileak ez badu onartzen token jaulkitzaileak zabaldu nahi duen bloke-kateen sare jakin bat, bi aukera ezin hobeak izango ditu: Itxaron zubi-hornitzaileak nahi den katearen euskarria gehi dezan arte, eta horrek denbora luzea behar izan dezake edo inoiz ez gerta daiteke integrazioaren kostu handien ondorioz (adibidez, ZKsync Era-ren EVM desberdintasuna, dapp asko bertan inoiz ez zabaltzea ekarri duena) Erabili beste zubi-hornitzaile bat kate zehatz horretarako, eta horrek token ez-fungigarrien eta likidezia zatitzearen arazoa berriro sartzen du Muga horrek nabarmen eragin dezake protokolo baten hazkunde-estrategian eta sortzen ari diren kateetan erabiltzaile berrietara iristeko gaitasunean. Zubi-hornitzaileek kate ezagunen laguntzari lehentasuna eman diezaiokete token jaulkitzailearentzat estrategikoki garrantzitsuak izan daitezkeen sare txikiagoak edo berriagoak alde batera utzita. 6. Zeharkako katearen token token helbideak ez-koherenteak Hirugarrenen zubi-hornitzaileek kate bakoitzean helbide desberdinak dituzten zubi-tokenak inplementa ditzakete beren teknologia-pilaren berezitasunak direla eta, adibidez, ren laguntzarik ez. Helbideen koherentzia faltak, aldi berean, UX arazo asko sortzen ditu: CREATE2- : Erabiltzaileek token helbide desberdinak egiaztatu behar dituzte kate bakoitzean, iruzurrezko tokenekin elkarreragiteko arriskua areagotuz; Segurtasun arriskuak : garatzaileek sare bakoitzeko baliozko token helbideen zerrendak mantendu behar dituzte; Integrazioaren konplexutasuna : aktore txarrek errazago engainatu ditzakete erabiltzaileak token faltsuekin, ez baitago egiaztatu beharreko helbide koherenterik. Phishing arriskua areagotu Eragozpen hauek, aurrez eztabaidatutako saltzaileen blokeoaren, subiranotasunaren galeraren eta zubi-hutsen esposizio handiaren arazoekin batera, hirugarrenen zubi kanonikoetan konfiantza izatearen muga nabarmenak azpimarratzen dituzte kate gurutzatutako token inplementazioetarako. Ulermen honek ERC-7281 bezalako irtenbide alternatiboak erronka horiei modu integralagoan aurre egiteko arrazoia ezartzen laguntzen du. 3. Atera token kanonikoak token-jaulkitzaileen zubiaren bidez Garatzaile batek proiektu baten token-kateen zeharkako inplementazioen kontrol maximoa mantendu nahi badu, tokenaren irudikapen kanonikoen igorpena kudeatu dezake urruneko kateetan. Hau "fiatu token jaulkitzailean" gisa deskribatzen da, tokenaren zubiaren irudikapen bakoitzaren balioa tokenaren hasierako katean blokeatuta dagoen tokenekin lotuta baitago iturburu-katean tokenaren jatorrizko bertsioa igortzeko ardura duen protokoloak. Ikuspegi horrek funtziona dezan, token-jaulkitzaileak azpiegitura konfiguratu behar du zubi-token kate gurutzatuan ateratzea eta erretzea kudeatzeko (hornikuntza globala sinkronizatuta mantentzen dela ziurtatuz mapa kanonikoaren bidez). Token sortzaileak jaulkitako token baten irudikapen kanonikoen adibide nabarmenak eta Circle's dira. MakerDAOren Teleport Cross-Chain Transfer Protocol (CCTP) Teleport-ek erabiltzaileei DAI kanonikoa mugitzeko aukera ematen die Ethereum eta Ethereum hainbat bilketa artean, bide azkar eta moteleko eragiketen bidez. DAI kate batean erretzen da eta xede-katean mintzen da. CCTPk antzera funtzionatzen du eta berezko USDC (Circle-k jaulkitako) kate gurutzatuak transferitzea ahalbidetzen du, erre eta menta mekanismo baten bidez. Bi kasuetan, token-jaulkitzaileak kontrolatzen du token baten irudikapen kanonikoak sortzea eta erretzea. Ikuspegi honek protokoloetarako zubi-tokenen kontrol osoa eskaintzen du. Eta token beraren irudikapen ez-fungigarrien arazoa ahalik eta modu eraginkorrenean konpontzen du: tokenaren bertsio kanoniko bakarra dago (helmuga-katean jaulkitzaileak egina), eta horrek erabiltzaileek token bat erabiliz esperientzia bera izango dutela bermatzen du. token jaulkitzaileak onartzen duen ekosistema guztietan. Planteamendu honekin, aplikazioek ekosistema berean flotatzen duten protokolo baten tokenen irudikapen ez-ofizial eta zubiek eragindako likidezia-zatiketa ezabatzeaz ere etekina ateratzen da. Garatzaileek kate arteko aplikazio sendoagoak ere eraiki ditzakete (adibidez, kate arteko trukeak eta kate arteko maileguak), token-jaulkitzaileen zubi kanonikoek kateen arteko tokenen mugimendu eraginkorra, eraginkorra eta segurua ahalbidetzen baitute. Token-jaulkitzaileen zubi kanonikoen alde txarra da, ordea, eredu hau bideragarria dela token-kate gurutzatua ezartzeko eta gurutzatzeko behar diren azpiegiturak (orakuluak, zaintzaileak, etab.) mantentzearen gain-kostuak estaltzeko kapital nahikoa duten proiektuetarako soilik. kate-atera eta erretzea. Honek, gainera, eragin desiragarria du zubi-aktiboen segurtasuna protokoloaren segurtasun-ereduarekin estu lotzea. Harreman hau (protokoloaren tokenen zubi-bertsioen eta protokoloaren segurtasunaren artekoa) adiskidetsua da, irudikapen kanonikoak babesten dituzten jatorrizko tokenen segurtasuna dagoeneko protokoloaren segurtasunaren araberakoa baita, erabiltzaileek eta kanpoko garatzaileek konfiantzazko hipotesi berriak hartzen ez dituztelako. Hau bereziki egia da Circle eta Maker (gaur Sky) bezalako jaulkitzaileek kudeatzen dituzten ; erabiltzaileek dagoeneko fidatzen dute stablecoin jaulkitzaileetan nahikoa aktibo izateko stablecoin moneta fidagarrien amortizazioa estaltzeko, beraz, stablecoin zubi baten segurtasunean fidatzea ez da zaila. stablecoin zubietan Baina huts-puntu zentral bat ere adierazten du: token jaulkitzailearen zubi-azpiegitura arriskuan jartzen bada, kate anitzeko ekosisteman zirkulatzen duten irudikapen kanoniko guztien balioa arriskuan dago. Horrek ere esan nahi du zaindari zentralizatuek soilik (adibidez, Circle USDCren kasuan) inplementatu dezaketela zubi-token kanonikoak jaulkitzeko eredu hau. Azken gogoetak Txosten honetan erakusten den bezala, kate gurutzatutako aktiboen fungikortasuna biltzeko elkarreragingarritasunaren zati garrantzitsu bat da, kate ezberdinen artean mugitzearen esperientzian ondorioak dituena. Tokenek fungigarriak izaten jarraitzeko gaitasunak urruneko kateetara lotzen direnean ere eragina du garatzaileen esperientzian, zenbait erabilera-kasu funtzio horren araberakoak baitira. Konponbide desberdinak proposatu dira kate gurutzatu gabeko tokenen arazoa konpontzeko, eta horietako asko txosten honetan azaldu ditugu. Honen artean, token kanonikoak jatorrizko zubien bidez (kontserbatuta) egitea, hirugarrenen zubi dedikatu bat erabiltzea token kanonikoak kate anitzetan egiteko eta protokoloaren jabetzako zubi bat erabiltzea tokenen mugimendua errazteko eta fungigarritasuna zaintzeko. Planteamendu hauek arazo zehatzak konpontzen dituzten arren, arazo guztiak ez dituzte konpontzen eta kate gurutzatutako aktiboen fungikortasuna ahalbidetzeko erabiltzeak desiragarrizko konpromezu batzuk eskatzen ditu. Aurki al dezakegu hurbilketa hoberik? Erantzuna baiezkoa da. ERC-7281 kate arteko aktiboen fungikortasunaren ikuspegi berria da, lehendik dauden planteamenduekin lotutako konpromezuak arintzen dituena. izenez ere ezaguna, ERC-7281-k protokoloak gaitzen ditu token kanonikoak modu eraginkorrean hedatzeko hainbat katetan segurtasuna, subiranotasuna edo erabiltzailearen esperientzia trukatu gabe. xERC-20 ERC-7281-ren diseinu bereziak hainbat zubi (zerrenda zurian) protokolo baten token bertsio kanonikoak egiteko aukera ematen du onartzen den kate guztietan, protokoloen garatzaileei zubi bakoitzeko aktatze-mugak dinamikoki doitzeko aukera ematen die. Ezaugarri honek kate anitzeko token kanonikoen proposamen historikoekin lotutako arazo asko konpontzen ditu, besteak beste, likidezia zatikatzea, pizgarrien lerrokatzea, UX kezkak, zubiaren segurtasun arriskuak, pertsonalizagarritasuna (kate gurutzatuen tokenak) eta abar. Kate arteko aktiboen fungigarritasunari buruzko gure bi zatiko txostenaren hurrengo eta azken zatiak ERC-7281 zehatz-mehatz landuko du eta xERC-20 token estandarrak garatzaileei eta erabiltzaileei nola onura diezaiekeen aztertuko du. ERC-7281 kate anitzeko token kanonikoen beste diseinu batzuekin alderatuko dugu, xERC-20-k kate anitzeko token kanonikoen ikuspegia aztertuko dugu eta estandarra eraiki nahi duten protokolo eta garatzaileentzako gogoetak nabarmenduko ditugu. Egon adi! Egilearen oharra: artikulu honen bertsio bat jatorriz argitaratu zen. hemen