Bevezetés
A Vitalik Buterin által 2014-ben alapított Ethereum a decentralizált alkalmazások (DAppok) létrehozására alkalmas, nyílt forráskódú platformként pozicionálta magát. Buterint részben a Bitcoin protokoll rugalmassági hiányosságai motiválták egy új blokklánc fejlesztésére.
Az Ethereum blokklánc az indulása óta vonzza a fejlesztőket és vállalkozókat, és megteremtette az okosszerződéseket, valamint az elosztott alkalmazásokat indító felhasználók egyre növekvő táborát.
Ebben a cikkben az ERC-20 szabványt vizsgáljuk meg, amely a tokenkibocsátás fontos keretrendszere. Bár a szabvány az Ethereum hálózat sajátja, sok más blokklánchoz is ihletet adott, például a Binance Chain BEP-2 láncához.
Mi az ERC-20 szabvány?
Az Ethereum hálózatán az ERC egy Ethereum-kérés vélemények kifejtésére (Ethereum Request for Comments). Ezek olyan műszaki dokumentumok, amelyek meghatározzák az Ethereumon végzett programozási tevékenységek szabványos kereteit. Nem szabad összekeverni őket az Ethereum-fejlesztési javaslatokkal (Ethereum Improvement Proposals – EIPs), amelyek a Bitcoin BIP-ekhez hasonlóan magára a protokollra vonatkozó fejlesztéseket tartalmazzák. Ehelyett az ERC-k célja olyan szabályok felállítása, amelyek megkönnyítik az alkalmazások és szerződések egymás közti kommunikációját.
A 2015-ben Vitalik Buterin és Fabian Vogelsteller által kidolgozott ERC-20 egy viszonylag egyszerű formátumot javasolt az Ethereum-alapú tokenekhez. Az iránymutatást követve a fejlesztőknek nem kell újra feltalálni a spanyol viaszt. Ehelyett egy olyan alapra építhetnek, amelyet ágazatszerte használnak.
Az ERC-20 tokenek a létrehozásuk pillanatától kezdve automatikusan kompatibilisek az ERC-20 szabványt támogató szolgáltatásokkal és szoftverekkel ( szoftvertárcákkal, hardvertárcákkal, tőzsdékkel stb.).
Megjegyzendő, hogy az ERC20-as szabványból egy EIP (konkrétan az EIP-20) született. Ez néhány évvel az eredeti javaslat után történt, mivel széles körben használni kezdték azt. Mégis, az ERC-20 megnevezés megmaradt.
Rövid összefoglaló az Ethereum tokenekről
Az ETH-től (az Ethereum natív kriptovalutájától) eltérően az ERC-20 tokenek egy számlán sincsenek jelen. A tokenek csak egy szerződésen belül léteznek, ami ennél fogva olyan, mint egy önmagában álló adatbázis. Meghatározza a tokenekre vonatkozó szabályokat (úgymint név, szimbólum, oszthatóság), és listát vezet a felhasználók egyenlegéről az Ethereum-címeikkel szemben.
A tokenek mozgatásához a felhasználóknak tranzakciót kell küldeniük a szerződésre, amellyel megkérik, hogy az egyenlegük egy részét máshová allokálja. Ha például Alíz 5000 BinanceAcademyTokent küldene Robinak, akkor a BinanceAcademyToken okosszerződésen belüli funkció lehívásával a szerződést kéri meg erre.
A kérését egy látszólag átlagos Ethereum tranzakcióba csomagolja a rendszer, ami 0 ETH-et fizet ki a tokenszerződés felé. A kérés a tranzakción belül egy másik mezőben is szerepel, amely pontosan meghatározza, hogy Alíz mit szeretne tenni – az esetünkben tokeneket szeretne küldeni Robinak.
Habár Alíz nem küld ethert, meg kell fizetnie az etherben kifejezett díjat, hogy a rendszer felvegye a tranzakcióját egy blokkba. Ha nincs ETH-je, akkor a tokenek elküldése előtt szereznie kell valahonnan.
Lássuk a fenti példa valóéletbeli megjelenését az Etherscanen: valaki kérést küld a BUSD-szerződés felé. Láthatjuk, hogy tokeneket küldtek és díjat fizettek, habár az Érték mezőben az látszik, hogy 0 ETH-et továbbítottak.
Most, hogy ráhangolódtunk a témára, nyissuk fel a motorháztetőt, hogy jobban megértsük egy tipikus ERC-20 szerződés felépítését.
Hogyan jönnek létre az ERC-20 tokenek?
Ahhoz, hogy ERC-20-kompatibilis legyen, a szerződésnek hat kötelező függvényt kell tartalmaznia. Ezek a következők: totalSupply(teljes kínálat), balanceOf(egyenleg), transfer(átutalás), transferFrom (átutalás innen), approve(jóváhagyás) és allowance(keret). Emellett opcionális függvények is megadhatók, például name(név), symbol(szimbólum) és decimal(tizedeshelyek). A megnevezésekből talán egyértelmű, hogy mire jók ezek a függvények. Ha mégsem, ne aggódjon, részletesen elmagyarázzuk őket.
Alább láthatók a függvények, ahogy az Ethereum saját fejlesztésű Solidity programnyelvén megjelennek.
totalSupply
function totalSupply() public view returns (uint256)Amikor egy felhasználó lehívja, akkor a fenti függvény a szerződésben található tokenek teljes kínálatát adja vissza.
balanceOf
function balanceOf(address _owner) public view returns (uint256 balance)A totalSupply-jal ellentétben a balanceOf egy paramétert használ (egy címet). Ha lehívják, az adott cím tokenállományának egyenlegét adja vissza. Ne feledje, hogy az Ethereum hálózaton létrehozott számlák nyilvánosak, szóval a cím birtokában Ön bármelyik felhasználó egyenlegét lekérdezheti.
transfer
function transfer(address _to, uint256 _value) public returns (bool success)A transfer megfelelő módon továbbítja a tokeneket egyik felhasználótól a másikhoz. Itt meg kell adnia a küldeni kívánt összeget és a címet, amelyre küldeni akarja.
Ha lehívják, a transfer függvény kivált egy úgynevezett eseményt – event – (ebben az esetben egy event transfer eseményt), amely alapvetően megmondja a blokkláncnak, hogy építsen be egy hivatkozást.
transferFrom
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)A transferFrom függvény a transfer praktikus alternatívája, amely egy kicsit tágabb programozhatóságot biztosít a decentralizált alkalmazásokban. A transfer függvényhez hasonlóan a transferFrom is tokeneket mozgat, de a tokeneknek nem feltétlenül kell a szerződést lehívó személy tulajdonában lenniük.
Más szóval Ön felhatalmazhat valakit – vagy egy másik szerződést – hogy az Ön nevében pénzeszközöket utaljon át. Ennek egyik lehetséges felhasználási célja az előfizetés-alapú szolgáltatások kifizetése, ahol Ön nem akarja minden héten/hónapban/évben manuálisan intézni a kifizetést. Ehelyett rábízza azt egy programra.
Ez a függvény ugyanazt az eseményt váltja ki, mint a transfer.
approve
function approve(address _spender, uint256 _value) public returns (bool success)Az approve egy másik hasznos függvény a programozhatóság szempontjából. Ezzel a függvénnyel Ön korlátozhatja azoknak a tokeneknek a számát, amelyeket egy okosszerződés lehívhat az egyenlegéből. Enélkül azt kockáztatná, hogy egy hibásan működő (vagy kizsákmányolt) szerződés miatt eltűnik az összes pénze.
Példáért forduljunk ismét az előfizetési modellünkhöz. Tegyük fel, hogy Ön nagy mennyiségű BinanceAcademyTokennel rendelkezik, és ismétlődő kifizetéseket szeretne beállítani egy streaming szolgáltatást nyújtó DApp felé. Éjjel-nappal a Binance Academy oldalait olvassa, így nem akar minden héten a tranzakciók manuális végrehajtásával időt pazarolni.
Hatalmas BinanceAcademyToken egyenlege van, amely messze meghaladja az előfizetés fedezéséhez szükséges összeget. Megakadályozandó, hogy a DApp mindet elvegye, Ön az approve függvénnyel beállíthat egy limitet. Tegyük fel, hogy az előfizetés ára hetente egy BinanceAcademyToken. Ha a jóváhagyott értéket húsz tokenben maximalizálja, akkor öt hónapon át automatikusan fizetheti az előfizetését.
Ha a DApp megpróbálja lehívni az összes pénzeszközét vagy valamilyen hiba történik, Ön a legrosszabb esetben akkor is csak húsz tokent veszít. Talán nem ideális megoldás, de minden bizonnyal kedvezőbb, mint a teljes vagyon elvesztésének lehetősége.
Ha lehívják, az approve kiváltja az approval eseményt. Ahogy a transfer esemény, ez is adatokat ír a blokkláncra.
allowance
function allowance(address _owner, address _spender) public view returns (uint256 remaining)Az allowance függvény az approve függvénnyel együtt használható. Amikor Ön engedélyt ad egy szerződésnek, hogy a tokenjeit kezelje, azt is ellenőrizheti, hogy a szerződés mennyi tokent hívhat még le. Például, ha az előfizetése a jóváhagyott húsz tokenből tizenkettőt már felhasznált, akkor az allowance függvénynek nyolcat kell eredményül adnia.
Opcionális függvények
A fent ismertetett függvények megadása kötelező. Ugyanakkor a name, symbol és a decimal függvényeket nem kell megadni, de picit csinosabbá teheti velük az ERC-20 szerződését. Ezek segítségével emberi nyelven olvasható neveket emelhet be, szimbólumot (pl. ETH, BTC, BNB) adhat hozzá, és meghatározhatja, hogy hány tizedesjegyig legyenek oszthatók a tokenek. Például a pénzként használt tokenek nagyobb hasznát láthatják az oszthatóságnak, mint azok, amelyek egy vagyontárgy tulajdonjogát képviselik.
Tekintse meg ezt a példát a GitHubon, hogy lássa egy valódi szerződés ezen elemeit.
Mit lehet csinálni az ERC-20 tokenekkel?
A fenti függvényeket összerakva egy ERC-20 szerződést kapunk. Lekérdezhetjük a teljes kínálatot, egyenlegeket ellenőrizhetünk, átutalást végezhetünk és engedélyt adhatunk más DAppoknak hogy tokeneket kezeljenek helyettünk.
Az ERC-20 tokenek báját a rugalmasságuk adja. A lefektetett szabályok nem korlátozzák a fejlesztést, így a felek további funkciókat valósíthatnak meg és az igényeiknek megfelelő konkrét paramétereket állíthatnak be.
Stabilcoinok
A stabilcoinok (fiat-valutákhoz rögzített tokenek) gyakran használják az ERC-20 tokenszabványt. A BUSD szerződés felé küldött, korábban hivatkozott tranzakció egy példája ennek, és a legtöbb nagy stabilcoin ebben a formátumban is elérhető.
Egy tipikus fiat-fedezetű stabilcoin esetén a kibocsátó euró-, dollár- stb. tartalékokat képez. Aztán a tartalékolt valuta minden egyes egységéért kibocsát egy tokent. Ez azt jelenti, hogy ha 10 000 amerikai dollárt zárnak egy páncélszekrénybe, akkor a kibocsátó 10 000 tokent hozhat létre, amelyek mindegyike beváltható 1 USD-re.
Ez technikailag elég könnyedén megvalósítható az Ethereum hálózatán. Egy kibocsátó egyszerűen elindít egy szerződést, 10 000 tokennel. Aztán kiosztja azokat a felhasználóknak azzal az ígérettel, hogy később visszaválthatják a tokeneket az arányos mennyiségű fiat-pénzre.
A felhasználók sok különböző dolgot tehetnek a tokenjeikkel, például termékeket és szolgáltatásokat vásárolhatnak velük vagy DAppokban használhatják őket. Emellett kérhetik azt is, hogy a kibocsátó azonnal váltsa be őket. Ebben az esetben a kibocsátó elégeti a visszaküldött tokeneket (használhatatlanná teszi őket), és a tartalékából lehívja a pontos fiat-összeget.
A felvázolt rendszert irányító protokoll – ahogy korábban említettük – viszonylag egyszerű. Ugyanakkor egy stabilcoin elindításához sokat kell dolgozni a külső tényezőkön, úgymint logisztika, jogszabályi megfelelés stb.
Értékpapír tokenek
Az értékpapírtokenek a stabilcoinokhoz hasonlók. A szerződések szintjén egyformák is lehetnének, mivel ugyanolyan módon működnek. A különbség a kibocsátó szintjén jelentkezik. Az értékpapírtokenek értékpapírokat, például részvényeket, kötvényeket vagy fizikai eszközöket testesítenek meg. Gyakran (bár nem minden esetben) valamilyen részesedést biztosítanak a tulajdonosnak egy vállalkozásban vagy egy áruban.
Hasznossági tokenek
A hasznossági tokenek manapság talán a legelterjedtebb tokentípust képviselik. A két korábbi lehetőséggel ellentétben ezek mögött nincs semmilyen fedezet. Ha az eszközfedezetű tokeneket egy légi társaság részvényeihez hasonlíthatjuk, akkor a hasznossági tokenek olyanok, mint a törzsutas programok: egy konkrét funkciót szolgálnak, de külső értékük nincs. A hasznossági tokenek számtalan felhasználási célt elégítenek ki, lehetnek például játékon belüli pénz, decentralizált alkalmazások üzemanyaga, hűségpontok és még sok minden más.
➠ Belépne a kriptovaluták világába? Vegyen ethert a Binance-en!
Az ERC-20 tokeneket lehet bányászni?
Az ethert (ETH) lehet bányászni, de a tokeneket nem. Amikor új tokenek létrejöttéről beszélünk, akkor azt mondjuk, hogy új tokeneket mintelnek. Egy szerződés elindításakor a fejlesztők a kínálatot a terveiknek és az ütemtervüknek megfelelően osztják szét.
Ezt általában egy elsődleges érmekibocsátás (Initial Coin Offering – ICO), elsődleges tőzsdei kibocsátás (Initial Exchange Offering –IEO) vagy egy értékpapírtoken-kibocsátás (Security Token Offering – STO) keretében teszik. Az említett mozaikszavak különböző variációkban fordulnak elő, de a koncepciójuk nagyon hasonló. A befektetők ethert küldenek a szerződéscímre, és cserébe új tokeneket kapnak. Az összegyűjtött pénzzel aztán a projekt további fejlesztését finanszírozzák. A felhasználók arra számítanak, hogy a tokenjeiket (azonnal vagy egy későbbi időpontban) használni tudják majd, vagy profittal adhatják el, ahogy a projekt fejlődik.
A tokenelosztásnak nem kell automatikusnak lennie. A felhasználók sok közösségi finanszírozású eseményen számos különböző digitális valutával (pl. BNB, BTC, ETH és USDT) fizethetnek. Ezt követően az egyenlegeket a felhasználók által megadott címekre küldik.
Az ERC-20 tokenek előnyei és hátrányai
Az ERC-20 tokenek előnyei
Helyettesíthető
Az ERC-20 tokenek egymással helyettesíthetők – minden egység helyettesíthető egy másik egységgel. Ha Önnek van egy BinanceAcademyTokenje, akkor mindegy, hogy pontosan melyik az Öné. Bárki más BinanceAcademyTokenjére elcserélheti, funkcionálisan akkor is egyformák lennének, pont mint a készpénz vagy az arany.
Ez akkor ideális, ha a token célja, hogy valamilyen pénznemként működjön. Ez esetben nem kívánatos, hogy az egyes egységek megkülönböztető tulajdonságokkal bírjanak, amelyek nem helyettesíthetővé tennék őket. Ennek következtében egyes tokenek nagyobb – vagy kisebb – értéket képviselnének a többinél, ami aláásná a felhasználási céljukat.
Rugalmasság
Ahogy az előző részben láthattuk, az ERC-20 tokenek sok tekintetben az egyéni igényekre szabhatók, így számos különböző alkalmazáshoz használhatók. Felhasználhatók például játékon belüli pénzként, hűségpontprogramokban, digitális gyűjteményként, de akár művészeti alkotást és tulajdonjogokat is képviselhetnek.
Népszerűség
Az ERC-20 népszerűsége a kriptovaluta iparágon belül nagy vonzerő arra, hogy alapként használják. Számtalan tőzsde, tárca és okosszerződés már eleve kompatibilis az újonnan elindított tokenekkel. Mi több, bőséges fejlesztői támogatás és dokumentáció is rendelkezésre áll.
Az ERC-20 tokenek hátrányai
Skálázhatóság
Sok más kriptovaluta-hálózathoz hasonlóan az Ethereum sem immunis a gyerekbetegségekkel szemben. Jelenlegi formájában nem túl jó a skálázhatósága. Ha valaki csúcsidőben próbál tranzakciót küldeni, azzal magas díjakat és késedelmeket vállal. Ha valaki elindít egy ERC-20 tokent és a hálózat lelassul, az a token használhatóságát is befolyásolja.
Ez a probléma nem csak az Ethereumnál jelentkezik. Hanem a biztonságos és elosztott rendszerek esetén szükséges kompromisszum. A közösség az említett problémák kezelésére tervezi az Ethereum 2.0 bevezetését, amely olyan fejlesztéseket valósít meg, mint az Ethereum Plasma és az Ethereum Casper.
Tudjon meg többet a skálázási problémákról a Blokkláncok skálázhatósága: Oldalláncok és fizetési csatornák című írásunkból.
Átverések
Bár nem magával a technológiával kapcsolatos probléma, a tokenkibocsátás könnyedsége bizonyos szempontokból hátránynak is tekinthető. Egy egyszerű ERC-20 tokent létrehozni minimális erőfeszítést jelent, vagyis bárki meg tudja tenni, jó és rossz céllal egyaránt.
Ezért nagyon óvatosnak kell lennie azzal kapcsolatban, hogy mibe fekteti a pénzét. Sok piramisjáték és Ponzi séma álcázza magát blokkláncprojektnek. Befektetés előtt nézzen utána a dolgoknak, és vonja le a saját következtetéseit egy lehetőség legitimitásával kapcsolatban.
ERC-20, ERC-1155, ERC-223, ERC-721 – mi a különbség?
Az ERC-20 a sorban az első (és a mai napig a legnépszerűbb) Ethereum tokenszabvány, de korántsem az egyetlen. Az évek során számos egyéb szabvány is kinőtte magát, ezek vagy az ERC-20-hoz készült fejlesztési javaslatok voltak, vagy teljesen más célokat kitűző elképzelések.
A kevésbé elterjedt szabványok között találjuk a nem-helyettesíthető tokenek (NFT-k) körében használtakat. Előfordul, hogy a felhasználási célnak éppen kedvező, ha különböző tulajdonságú, egyedi tokenjeink vannak. Ha egy egyedülálló műalkotást, egy játékon belüli eszközt stb. szeretnénk tokenizálni, akkor egy ilyen szerződéstípus vonzóbb lehet.
Az ERC-721 szabványt használták például a hihetetlenül népszerű CryptoKitties DApp elkészítéséhez. Egy ilyen szerződés egy API-t bocsát a felhasználók rendelkezésére, hogy elkészíthessék a saját nem-helyettesíthető tokenjüket, és metaadatokat (képeket, leírásokat stb.) adjanak hozzá.
Az ERC-1155 szabvány az ERC-721 és az ERC-20 továbbfejlesztésének egyaránt tekinthető. Olyan szabványt vázol fel, amely egyazon szerződésen belül a helyettesíthető és a nem-helyettesíthető tokeneket is támogatja.
Az egyéb opciók – például az ERC-223 vagy az ERC-621 – a használhatóság javítását célozták. Az ERC-223 védelmi elemeket tartalmaz a véletlen tokenátutalások megelőzése érdekében. Az ERC-621 pedig extra függvényeket tartalmaz a tokenkínálat növeléséhez és csökkentéséhez.
Az NFT-kkel kapcsolatos további információkért tekintse meg az Útmutató a kriptogyűjteményekhez és a nem-helyettesíthető tokenekhez (NFT) című cikkünket.
Záró gondolatok
Az ERC-20 szabvány éveken át dominálta a kriptoeszközök világát, és könnyen belátható, hogy miért. Bárki viszonylag könnyedén létrehozhat egy egyszerű szerződést egy sor különböző felhasználási célra (hasznossági tokenek, stabilcoinok stb.). Ezzel együtt az ERC-20-ból valóban hiányoznak bizonyos funkciók, amelyeket más szabványok hívtak életre. Hogy az utána érkezett szerződések átveszik-e a helyét, az még a jövő zenéje.