Az ERC-20 tokenekről részletesen

token-urile ERC-20 Az ERC20 tokenekről crypto hírek mycryptoption

Az ERC-20 tokenekről valószínűleg már te is hallottál, de csak kevesen tudják ezeket pontosan meghatározni. Tehát, mik is az ERC-20 tokenek?

Ezek olyan tokenek, amelyeket kizárólag az Ethereum platformon terveztek és használtak. Követik a szabványok listáját, így megoszthatók, cserélhetők más tokenekre, vagy átutalhatók digitális kripto-pénztárcába. Az Ethereum közösség ezeket a szabványokat három opcionális, valamint hat kötelező szabállyal hozta létre. Az ERC-20 tokenekről nem olyan egyszerű mindent szavakba önteni. Ha a kripto-világra gyakorolt hatásukat szemléljük, akkor elmondhatjuk a következőt: egyedül ezek felelősek a milliárd dolláros ICO-iparért, és nagy szerepet játszottak kriptovaluták hatékonyabb érvényesítésében is.

Az intelligens szerződésekhez vezető út

A blokklánc technológia és a kriptovaluták akkor kerültek előtérbe, amikor egy névtelen fejlesztő, Satoshi Nakamoto létrehozta a Bitcoint. A Bitcoin számos okból volt forradalmi. Első alkalommal jött létre olyan valutarendszer, amely az emberek, a felhasználók tulajdonában volt. Segítségével bárki utalhatott Bitcoint digitális pénztárcájával, anélkül, hogy banki szolgáltatásokat kellett volna igénybe vennie.

Annak érdekében, hogy a világot bevezessék a blokklánc technológia használatába, a Bitcoin közismert neve „első generációs blokklánc” lett. Ugyanakkor óriási korlátok vannak a Bitcoin tranzakcióinak végrehajtására vonatkozóan. Ha szeretnél pénzt küldeni a barátodnak egy egyszerű és egyéni tranzakció keretein belül, akkor ebben az esetben a Bitcoin lesz az ideális megoldás számodra. De mi lenne, ha csak akkor akarsz pénzt küldeni a barátodnak, ha egy bizonyos feladatot egy meghatározott határidőn belül befejez. Hogyan manipulálhatod a tranzakciós kódot az ilyen összetett tranzakciók elszámolására? Erre a kérdésre ad választ Vitalik Buterin az Ethereum létrehozásával.

Az Ethereum és az intelligens szerződések

Vitalik Buterin ráeszmélt arra, hogy a blokklánc technológiának sokkal több felhasználási módja lehetséges, mint pusztán fizetési rendszer. A honlapjuk szerint:”Az Ethereum egy decentralizált platform, amely okos szerződéseket futtat. Olyan alkalmazásokat, amelyek pontosan a programozás alapján működnek, kiesési idő, cenzúra, csalás vagy harmadik fél beavatkozása nélkül. Ezek az alkalmazások egy egyedileg épített blokkláncon futnak, egy rendkívül nagy teljesítményű megosztott globális infrastruktúrán, amely képes az értéket mozgatni és az ingatlan tulajdonjogát is képviselni.”

Egyszerűbb szavakkal fogalmazva: az Ethereum egy decentralizált szuperszámítógéppé válik, ahol bárki bárhol bérelhet számítási teljesítményt és létrehozhat olyan decentralizált alkalmazásokat (Dapps), amelyek az Ethereum platformon futnak majd. Szóval, hogyan készítheted ezeket a Dapp-okat? Ahhoz, hogy erre a kérdésre választ kapj, meg kell vizsgálnunk az intelligens szerződéseket.

Az intelligens szerződések automatikus szerződések. Önállóan végrehajtják a kódba írt speciális utasításokat, amelyek bizonyos feltételek teljesítésekor végrehajtódnak.

Az intelligens szerződések teszik lehetővé a dolgok elvégzését az Ethereum ökoszisztémájában. Ha valaki egy adott feladatot elvégez az Ethereumban, akkor biztosan intelligens szerződést fog kezdeményezni egy vagy több emberrel. Térjünk most vissza az előző szakaszhoz.

Az intelligens szerződések segítenek egyszerűsített formában kódolni a bonyolult tranzakciós részleteket. Nick Szabo találta ki őket. Elmondása szerint az intelligens szerződés legjobb valós életbeli példája nem más, mint az árusító automaták. Ha szeretnél valamit az automatából, akkor egyszerűen pénzt teszel be a gépbe, majd kiválasztod, amit akarsz, és a gép majd végrehajtja azt neked. Közvetlenül kölcsönhatásba lépsz a géppel, harmadik személy bevonása nélkül. Mindaddig, amíg a következő folyamatot követed:

  • Pénz behelyezése
  • A termék kiválasztása

…éééés meg is kapod, amit kértél. Tegyük fel, hogy te és egyik barátod, Zoli intelligens szerződések igénybe vételével szeretnétek interakcióba lépni egymással. Az intelligens szerződés ugyanígy működik. Belefoglalod az Ether egy részét (az Ethereum tokent) az intelligens szerződésbe, azzal a feltétellel, hogy amint Zoli befejez egyes feladatokat, a szerződés feloldja a letétbe helyezett pénzt, és elküldi azt Zoli tárcájába. 

Intelligens szerződések és ICO-k

Az intelligens szerződések egy teljesen új világot nyitottak meg a fejlesztők számára. Ezeknek a fejlesztőknek azonban szükségük volt egy módra, amely segítségével finanszírozhatják projektjeiket. Mi a megoldás? Az ICO-k. Az ICO-k vagy az Initial Coin Offerings az IPO-k  vagy Initial Public Offerings kriptopénz változata. Az IPO-khoz viszonyítva azonban az ICO-k sokkal vállalkozóbarátabbak a következő okok miatt: 

  • Először is, sokkal egyszerűbb a projekt bemutatása az ICO-kban. Csak annyit kell tenni, hogy bemutatod a projekt whitepaperét.
  • Bárki befektethet egy olyan projektbe, amely érdekli őt, megvásárolva az adott DAPP tokeneit, ezáltal máris a projekt részévé válhat.

Az ERC-20 tokenekről bővebben

Még egy dolgot tudnod kell, mielőtt megismerkednénk az ICO működésével. A fejlesztőknek adniuk kell valamit a beruházások ellenében. Ezt a “valamit” pedig tokennek hívják. Annak érdekében, hogy széles, és nem általánosított meghatározást kapj az ERC-20 tokenekről, a token valamit képvisel az adott ökoszisztémájában. Különböző szerepei vannak: értéket képviselhet, téttel járhat, szavazati jogot vagy akár más jogokat is biztosíthat. A token nem korlátozódik egy adott szerepre. Sok szerepet tölthet be natív ökoszisztémájában.

Szóval, milyen „szerepeket” tölthetnek be a tokenek?

  • Díj: Egy token hozzáférésként szolgálhat a Dappokhoz. Alapvetően ahhoz, hogy hozzáférj a Dapp-hoz, tokennel kell rendelkezned.
  • Szavazati jogok: A tokenek arra is feljogosíthatják a tulajdonosokat, hogy bizonyos szavazati jogokkal rendelkezzenek. Gondolj az EOS-ra, ha az EOS-tokenek birtoklása lehetővé teszi, hogy szavazzon a blokkészítőkre.
  • Csereeszköz: Ez a tokenek egyik leggyakoribb szerepe az ökoszisztémában. A tokenek segíthetnek az alkalmazáson belüli belső gazdasági rendszer létrehozásában.
  • Felhasználói élmény fokozása: A token lehetővé teszi a tulajdonosok számára, hogy gazdagítsák a felhasználói élményt az adott környezet határain belül. Például A Brave-ben (ami egy böngésző) a BAT (a Brave-ben használt token) birtokosainak joguk van arra, hogy gazdagítsák a vásárlói élményt, azáltal, hogy tokeneikkel hirdetéseket vagy más figyelem-alapú szolgáltatásokat adnak hozzá a Brave-platformon.
  • Pénznem: Értéktárolóként is használható. Tranzakciók lebonyolítására használható a megadott ökoszisztémán belül és kívül.

Tehát eddig elmondtuk, hogyan működnek az intelligens szerződések, az ICO-k és a tokenek. Ugyanakkor itt szembe is találtuk magunkat az első akadállyal. Vegyünk például egy játékgépet. Gondolj egy régi videojáték-árkádjára. Milyen lépéseket is kell tenned, mielőtt elkezded játszani a játékot:

  • Veszed a fiat pénzedet, és konvertálod azokat játék érmékké.
  • Az játék érmékkel játékot játszhatsz a gépeken, ha behelyezed őket a nyílásba. A nyílásokat úgy alakították ki, hogy kör alakú érméket fogadjanak el.
  • Miután elkészült, elveszi a fennmaradó érméket, ha vannak ilyenek, és konvertálja azokat fiat pénzre.

Tehát mostmár minden bizonnyal tudsz párhuzamot vonni a játékgép és az intelligens szerződéses platform között. A videojáték gépek a Dapp, míg a kibocsátott játék érmék a te natív tokenjeid. A Dapp szolgáltatásaihoz való hozzáféréshez rendelkezned kell ezekkel az érmékkel.

Ennek a rendszernek azonban van egy problémás területe. Annak érdekében, hogy illeszkedjenek a gép nyílásába, az érméknek meghatározott méretűnek kell lenniük. Mi lenne, ha olyan gépek jönnének létre, amelyek nem fogadnák el a kör alakú érméket, és inkább a szögletes érmealakot részesítenék előnyben? Ahhoz, hogy az üzlet zökkenőmentesen működjön a játékgép tulajdonosának meg kell határoznia egy alapszabályt. Minden gépet úgy kell gyártani, hogy elfogadja a kör alakú érméket. Más formát nem fogadhat el. Lényegében ez az, amit az ERC-20 irányelv végez. Régebben úgy tűnt, hogy minden egyes ICO token megpróbálta “feltalálni a spanyol viaszt” a végrehajtás szempontjából. Minden tokennek megvannak a saját funkcióinak listája. Ez pedig új problémák sorához vezetett.

Az egészséges ökoszisztéma létrehozásához elengedhetetlen, hogy Dapp-ok zökkenőmentesen kölcsönhatásba lépjenek egymással. Mi történik azonban akkor, ha két tokenünk van, mondjuk a Token Alpha és a Token Beta, és mindkettő eltérő intelligens szerződéses struktúrával rendelkezik? Ahhoz, hogy ez megtörténjen, a fejlesztőknek gondosan meg kell vizsgálniuk mindkét szerződést, és pontosan meg kell határozniuk, hogy ezek a tokenek hogyan fognak kölcsönhatásba lépni egymással.

Ha száz különféle token létezik száz különféle szerződéssel, nagyon komplex számítási kapacitás szükséges ahhoz, hogy meghatározzuk, mely szerződések képesek kommunikálni egymással. Ez pedig egyáltalán nem nevezhető ideális esetnek. Valamit tenni kellett, és 2015. november 19-én Fabian Vogelsteller talált egy ötletes megoldást.

A Wikipedia szerint az ERC-20: “Olyan szabályok listája, amelyet minden Ethereum tokennek implementálnia kell, lehetővé téve a fejlesztők számára, hogy leprogramozzák az új tokenek működését az Ethereum ökoszisztémán belül.” Az ERC-20 token szabvány népszerűvé vált azon közösség finanszírozási vállalatok körében, amelyek ICO-kon dolgoznak. Az egyszerűség kedvéért az ERC-20 olyan szabályok és rendeletek összessége, amelyek elősegítik az Ethereum-alapú intelligens szerződések tokenjeinek létrehozását. Az “ERC” az Ethereum Request for Comment (megjegyzéskérelem) jelent, míg a “20” szám e kérelemhez rendelt szám. Tehát, most, hogy az ERC-20 tokenekről átfogóbb tudást szereztél, ássunk mélyebbre tovább, és nézzük meg, mi történik a színfalak mögött.

Az ERC20 tokenekről “anatómiai” szempontból

A kötelező szabályok a következők:

totalSupply (Teljes készlet)
balanceOf (egyenleg)
transfer (átutalás)
transferFrom (utalás kezdeményezője)
approve (jóváhagyás)
alowance (jóváhagyhatóság)

Másrészt az opcionális szabályok a következők:

Token neve
szimbólum
Tizedes (18-ig)

A három opcionális szabály

Annak ellenére, hogy nem szükséges megnevezni a tokeneket, mégis fontos, hogy valamilyen identitást adjunk meg. A név valahogy így van meghatározva:

string public constant name = “Token Name”;

Aztán ott vannak a szimbólumok. Egyszerűen nem becsülhetjük alá azok fontosságát. A tökéletes példa erre az OmiseGO. Az emberek sokkal jobban ismerik az OMG-t, mint az OmiseGO-t. A megragadó szimbólum segít a jobb márkaépítésben. A feltüntetés módja:

string public constant symbol = “SYM”;

Végül megvan az az oszthatóság, amely segít meghatározni a token lehető legalacsonyabb értékét. A 0 oszthatósága azt jelenti, hogy a token legalacsonyabb értéke 1. A 2 oszthatósága viszont azt jelenti, hogy annak legkisebb értéke 0,01 lesz. A tizedesjegyek megengedett maximális száma 18. Ezt a következőképpen deklarálják:

uint8 public constant decimals = 18;

Rendben, nézzük csak a következő hat kötelező szabályt.

#1 totalSupply

A [totalSupply] a létrehozott ERC-20 tokenek számát azonosítja. Ennek a módszernek az a célja, hogy meghatározza az ökoszisztémában lévő tokenek számát.

A kód így néz ki:

contract MyERCToken {


uint256 _totalSupply = 1000000
 

 function totalSupply() constant returns (uint256 theTotalSupply) {


    theTotalSupply = _totalSupply;


   return theTotalSupply;

 }


}

#2 balanceOf

A balanceOf függvény visszaadja azon tokenek számát, amelyek egy adott cím, ebben az esetben a szerződéstulajdonos számláján vannak.

A kód így néz ki:

contract MyERCToken {


// Create a table so that we can map addresses


 // to the balances associated with them


mapping(address => uint256) balances;


 // Owner of this contract


 address public owner;


 function balanceOf(address _owner) constant returns (uint256 balance) {


 // Return the balance for the specific address


   return balances[_owner];


 }


}

#3 approve()

Az egyenleg ellenőrzése után a szerződéstulajdonos jóváhagyhatja a felhasználónak, hogy összegyűjtse a szükséges számú tokeneket a szerződés címéről. Ez a funkció ellenőrzi a tranzakciót a teljes tokenkészlettel szemben, hogy megbizonyosodjon arról, hogy van-e hiányzó vagy többlet token. Más szavakkal: biztosítja a hamisítás lehetetlenségét.

Megjegyzés: Az „msg.sender” a szerződés tulajdonosának címe.

contract MyERCToken {


// Create a table so that we can map


 // the addresses of contract owners to


 // those who are allowed to utilize the owner's contract


 mapping(address => mapping (address => uint256)) allowed;


 function approve(address _spender, uint256 _amount) returns (bool success) {


   allowed[msg.sender][_spender] = _amount;


   // Fire the event "Approval" to execute any logic


   // that was listening to it


   Approval(msg.sender, _spender, _amount);


   return true;


 }


}

#4 transfer()

Tehát most, hogy az összes ellenőrzés megtörtént, és a szerződés tudja, hogy a felhasználó rendelkezik a tranzakció befejezéséhez szükséges token-számmal. A szerződés tulajdonosa a #4 transfer() függvény használatával tokeneket küldhet. Ez a funkció lehetővé teszi a szerződés tulajdonosának, hogy egy adott összegű tokent egy másik címre küldjön, akárcsak a szokásos kriptovaluta tranzakcióknál. A játék megkezdése előtt a játékosoknak meg kell kapniuk az úgynevezett “BLU”-t a kereskedőtől.

contract MyERCToken {


 mapping(address => uint256) balances;



 // Note: This function returns a boolean value


 //       indicating whether the transfer was successful



function transfer(address _to, uint256 _amount) returns (bool success) {



   // If the sender has sufficient funds to send



   // and the amount is not zero, then send to



   // the given address



   if (balances[msg.sender] >= _amount



     && _amount > 0



     && balances[_to] + _amount > balances[_to]) {



     balances[msg.sender] -= _amount;



     balances[_to] += _amount;




     // Fire a transfer event for any



     // logic that's listening




Transfer(msg.sender, _to, _amount);



       return true;



     } else {

       return false;


     }


  }



} 

#5 transferFrom()

Na várjunk csak….Már tárgyaltuk az átviteli függvényt, miért van egy másik?

Vegyünk egy példát, hogy lásd, miért olyan nagyszerű kiegészítése a TransferFrom az ERC-20 szerződésnek.

Mindannyiunknak kell valamilyen összeget fizetnünk havonta. Lehet, hogy a bérleti díjat, a számlákat stb. Ezeket az összegeket nem kötelező készpénzben kifizetni. Mindig igénybe lehet venni egy automatikus fizetési lehetőséget egy bankon keresztül. Ez az, ami lehetővé teszi a transferFrom(). Segít automatizálni egy adott számlára történő átutalást.

A kód:

contract MyERCToken {


 mapping(address => uint256) balances;



 function transferFrom(address _from, address _to, uint256 _amount) returns (bool success) {



  if (balances[_from] >= _amount



    && allowed[_from][msg.sender] >= _amount



     && _amount > 0



     && balances[_to] + _amount > balances[_to]) {



   balances[_from] -= _amount;



   balances[_to] += _amount;



   Transfer(_from, _to, _amount);



     return true;



   } else {



     return false;



   }



 }



}

#6 allowance()

A tranzakció végrehajtása érdekében az egyik legfontosabb adat, amelyet a szerződésnek tudnia kell, a felhasználó egyenlege. Végül is a felhasználónak rendelkeznie kell a tranzakció lebonyolításához szükséges minimális token mennyiséggel. Ez az oka annak, hogy az ERC-20 szerződés tartalmazza ezt is. Ha a felhasználó nem rendelkezik a szükséges minimális mennyiségű tokennel, akkor a funkció törli a tranzakciót.

A kód:

function allowance(address _owner, address _spender) constant returns (uint256 remaining) {


   return allowed[_owner][_spender];


  } 

A kód összesítése

Tehát, most, hogy megláttuk, hogyan működnek az egyes funkciók, vessünk egy pillantást az ERC-20 token szerződésre.

A kód a GitHub-ból származik.

pragma solidity ^0.4.15;



contract MyERCToken


{



 // Create a table so that we can map addresses



 // to the balances associated with them




 mapping(address => uint256) balances;




 // Create a table so that we can map



 // the addresses of contract owners to



 // those who are allowed to utilize the owner's contract







 mapping(address => mapping (address => uint256)) allowed;





 // In this case, the total supply



 // of MyERCTokeis fixed, but



 // it can very much be changed



 uint256 _totalSupply = 1000000;



 // Owner of this contract




 address public owner;

 

function totalSupply() constant returns (uint256 theTotalSupply) {




   // Because our function signature



   // states that the returning variable


   // is "theTotalSupply", we'll just set that variable



   // to the value of the instance variable "_totalSupply"



   // and return it




   theTotalSupply = _totalSupply;




   return theTotalSupply;



 }



 function balanceOf(address _owner) constant returns (uint256 balance) {



   return balances[_owner];



 }



 function approve(address _spender, uint256 _amount) returns (bool success) {



   allowed[msg.sender][_spender] = _amount;



 // Fire the event "Approval" to execute any logic



   // that was listening to it



   Approval(msg.sender, _spender, _amount);



   return true;




 }



 // Note: This function returns a boolean value



 //       indicating whether the transfer was successful



 function transfer(address _to, uint256 _amount) returns (bool success) {




   // If the sender has sufficient funds to send



   // and the amount is not zero, then send to



   // the given address




 if (balances[msg.sender] >= _amount



     && _amount > 0



     && balances[_to] + _amount > balances[_to]) {



     balances[msg.sender] -= _amount;



     balances[_to] += _amount;




     // Fire a transfer event for any



     // logic that's listening




     Transfer(msg.sender, _to, _amount);



       return true;



     } else {



       return false;



     }



  }





  function transferFrom(address _from, address _to, uint256 _amount) returns (bool success) {



   if (balances[_from] >= _amount



     && allowed[_from][msg.sender] >= _amount



     && _amount > 0



     && balances[_to] + _amount > balances[_to]) {



   balances[_from] -= _amount;



   balances[_to] += _amount;



   Transfer(_from, _to, _amount);



     return true;



   } else {



     return false;



   }



 }


 function allowance(address _owner, address _spender) constant returns (uint256 remaining) {



   return allowed[_owner][_spender];



 }




 // Triggered whenever approve(address _spender, uint256 _value) is called.



 event Approval(address indexed _owner, address indexed _spender, uint256 _value)



 // Triggered when tokens are transferred.



event Transfer(address indexed _from, address indexed _to, uint256 _value);



}

Az ERC20 tokenekről. Miért előnyösek?

Most, hogy tudjuk, mi az ERC20, feltevődik az a kérdés, hogy miért előnyös annak használata?

Először is, a kényelem szempontájól. Mint már korábban kijelentettük, ha mindenki saját tokeneket készítene saját funkciókkal, akkor az interoperabilitás rémálom lenne. Sőt, szinte fájdalmas lenne, ha ezeket a tokeneket listáznánk a tőzsdéken. A tokenek utalásai tönkretehetik a szerződéseket és sebezhetővé tehetik a hackerek számára.

Egy igen fontos tényező, amely kritikus jelentőségű az Ethereum hálózat általános értékelése szempontjából, az ERC-20 tokenek likviditása. Ha az Ethereum csúcsán lévő projektek aktívak és interakcióba lépnek egymással, akkor ez több projektet eredményez és azt, hogy több felhasználó kerül az Ethereum hálózatba.

Az ERC-20 tokenekről hibáik szempontjából

Az első hiba a Transfer() bug. Bár az ERC-20 tokeneknek nagyon sok jó tulajdonságuk van, sok kritika is éri őket. Az Ethereumban kétféle fiók létezik: külső tulajdonban lévő fiókok (EOA), amelyeket privátkulcsok irányítanak, és szerződéses fiókok, amelyeket szerződés-kódjuk irányít. Ha kapcsolatba akarsz lépni egy másik EOA-fiókkal, akkor a Transfer () funkcióval átutalhatod a szükséges tokeneket. Ha azonban egy szerződéses fiók számára a Transfer () funkcióval szeretnéd elküldeni a tokeneket, akkor egy hibával fogsz szembesülni, amely már közel millió dolláros veszteségekhez vezetett. A Transfer () funkcióval az a nagy probléma, hogy a végrehajtás után a címzettet nem értesítik az átutalásról, még akkor sem, ha a tranzakció sikeresen megy végbe.

Egy “Dexaran” nevű fejlesztő hívta fel a figyelmet az adott problémára. Elmondása szerint:

“A token tranzakciója a szerződés belső változóinak cserélődése (a feladó” egyenlege “csökken, és a címzett” egyenlege “növekszik). Ennek eredményeként, ha a címzett szerződéses, akkor a felhasználóknak approve +transferFrom mechanizmussal kell átutalniuk tokeneiket. Ha a címzett egy külső cím, akkor a felhasználóknak “transfer”funkcióval kell utalniuk tokeneiket. Ha egy felhasználó hibát követ el, és rossz funkciót választ, akkor a token “beragad” a szerződésbe. Ez azt jelenti, hogy a szerődés nem hajtja végre az utalást. A beragadt tokeneket nem lehet már kinyerni. Tényleg létezik olyan tokenfejlesztő aki azt gondolja, hogy a felhasználók soha nem fognak effajta hibát ejteni?

Tehát ez nagyon jó lehetőség a jóváhagyás () és a transferFrom () kombinációra nézve? Azonban egy probléma is felmerül. Ez nem egy biztonságos művelet, ugyanis kettős elköltéses támadáshoz vezethet.

A második hiba az, hogy a belépési pont túl alacsony. Egy másik ok, ami miatt kritika éri ezeket az, hogy az ERC-20 túl könnyűvé tette az emberek számára, hogy saját tokeneket hozzanak létre. Ennek eredményeként a piacot elárasztják a felesleges tokenek.

Az ERC-20 tokenek jövője

Noha igaz, hogy az ERC20 tokennek fontos szerepe volt a kriptoökoszisztéma növekedésében, továbbra is tény, hogy valószínűleg “visszaéltek a vendégszeretettel”. Az emberek már kísérleteznek olyan újabb szabványokkal, mint az ERC223, ERC 777 stb., De jelenleg az ERC20 marad.

Dexaran a következő okokra sorakoztatja fel, hogy miért továbbra is az ERC-20 szabványt részesítik előnyben:

  • A tokenfejlesztők felelőtlenségének büntetlensége miatt.
  • Mivel az Ethereum még akkor is népszerűsíti az ERC20 token szabványt, ha közismert, hogy hibákat tartalmaz. Ugyanaz a helyzet, mint korábban a TheDAO-val. Azt kellene mondaniuk, hogy „azonnal hagyja abba használatukat”, de nem ezt fogják tenni.
  • A token fejlesztések legfőbb célja inkább a tőke bevonzása, mintsem termék létrehozása.
  • Mivel egy másik szabvány használata magasabb hálózati hatásokhoz vezet. Nem igazán erre van szükségünk, mivel az Ethereum hálózat már rendelkezik skálázhatósági problémákkal.

A változás mindig egy lassú folyamat, és úgy tűnhet, hogy mindenképpen várnunk kell még egy keveset, mielőtt más szabványokra válthatunk. Ne kövessük el azonban azt az hibát, hogy az ERC-20 szabványt degradáljuk. Minden bizonnyal tiszteletet érdemel a kripto-térre gyakorolt mély hatása miatt.

Érdekelnek a kriptopénzek? Ne maradj le a legérdekesebb infókról, csatlakozz hozzánk a lenti elérhetőségeken!

 KezdőknekKözösség Egyéb
 Bitcoin Útmutató Likeolj minket Facebookon! Legfrissebb Hírek
Ethereum Útmutató Csatlakozz Discord-on! Videók
 Kripto Szótár Kövess minket Youtuben is! Altcoinok

Tetszik a tartalom? Hívj meg minket egy kávéra! 

Útmutatóink, tanulmányaink és minden tartalmunk teljesen ingyenes! Affiliatekből és támogatásokból tartjuk fent az oldalt. Ha szeretnél te is hozzájárulni, hogy az oldal továbbra is fennmaradjon és minőségi tartalmat közvetítsen, akkor támogass minket egy kávé árával kriptóban.

BTC: bc1qp2ux3zjszpnlq8nhylek4nqkgk6ku4cm7er4tt

ETH: 0xbeCf9703c70e0A08096C41E4c86A1C75043d8135

Még több cikk