ERC 20 vs ERC 223 vs ERC 777: Az Ethereum token szabványok összehasonlítása

Ön Ethereum fejlesztő, aki kriptoprojekten dolgozik? Valószínűleg az ERC20 szabvány használatával fejleszti az új tokent, azonban ismernie kell a fejlesztési erőfeszítéseket. Ez segít meghozni a megfelelő döntést arról, hogy melyik ERC token szabványt használja, ezért ebben a cikkben elmagyarázom az ERC777 vs ERC223 vs ERC20 összehasonlítást..

Az összehasonlítást az ERC 20 magyarázatával kezdem, majd később kifejtem annak hátrányait. Ezután elmagyarázom azokat a fejlesztési erőfeszítéseket, amelyeket az Ethereum közösség vállalt az ERC 777 és az ERC 223 révén.

Az ERC20 és az ERC223 és az ERC777 összehasonlítása

ERC 20 vs ERC 223 vs ERC 777

Mi az ERC 20?

Mielőtt összehasonlítanám az ERC 20 és az ERC 223 és az ERC 777 összehasonlítását, meg kell magyaráznom, mi az ERC, és mit jelent az ERC20. Az Ethereum fejlesztői gyakran nyújtanak be „Ethreum Improvement javaslatokat” (EIP). Az Ethereum közösség felülvizsgálja az EIP-ket, megjegyzéseket tesz, amelyek némi átdolgozást válthatnak ki.

Miután az Ethereum közösség elfogadta az EIP-t, az szabványossá válik, és ezt követően „Ethereum Request for Comments” -nek (ERC) hívtuk. Az ERC 20 az Ethreum tokenek egyik ilyen szabványa.

Az ERC 20 a leghíresebb Ethereum token szabvány, és szinte az összes Ethereum platformot használó ICO használta. A fejlesztők alapértelmezés szerint új tokenek létrehozására használják, míg a pénztárcák és a központok könnyen elfogadják az ERC 20 tokent.

Az ERC 20 előtt az Ethereum fejlesztőinek külön szabályokat kellett meghatározniuk, amelyeket a tokenjük követni fog, és ez a megközelítés hiányzott a szabványosításból. Az ERC20-mal az Ethereum fejlesztői tudják, hogy csak az ERC 20 szabványt kell használniuk. Ez a szabványosítás nagy szerepet játszott az ICO-őrület táplálásában, amelyet 2017 óta láttunk.

További információ az ERC 20 szabványról: „Kezdő útmutató: Mi az az ERC20?”.

Mik az ERC 20 szabványos funkciói?

Az ERC 20 szabvány a következő funkciókat írja elő az Ethereum token fejlesztésekor:

  1. Kapja meg a tokenek teljes készletét: Használnia kell a „totalSupply” függvényt.
  2. Szerezzen be egy másik tulajdonosi fiók token egyenlegét.
  3. Tokenek küldése egy másik tulajdonos fiókhoz: Használnia kell az „átviteli” funkciót. Ezek a számlák EOA-számlák.
  4. Tokeneket küldhet egyik token címről a másikra. A token címek szerződéses címek, és használnia kell a „transferFrom” függvényt.
  5. Engedje meg, hogy egy másik számla ismételten, meghatározott határokon belül vegyen fel pénzt a számlájáról. Ehhez használja a „jóváhagyás” funkciót.
  6. A költők a fel nem használt tokent visszaadhatják a tulajdonosoknak az „engedély” funkció használatával.

Az ERC 20 hibája, amely tokent éget


Noha az ERC 20 szabvány nagyon jól dokumentált és megvalósított, hibája van, és ez már több millió dollár értékű tokent égetett. A „transzfer” funkció csak lehetővé teszi, hogy tokeneket küldjön egy másik tulajdonosnak, azaz EOA-fióknak.

Ha pénzt szeretne elküldeni egy intelligens szerződéses számlára, vagyis az Ethereum számlák másik formájára, akkor az „jóváhagyás” és a „transzferFrom” kombinációt kell használnia. Ha tokeneket küld egy intelligens szerződésnek az „átutalás” funkció használatával, sikeres tranzakciót fog látni, de a szerződés soha nem kapja meg a tokent.

Ez örökre megégeti ezeket a tokeneket, és nem tudja letölteni őket. Számos felhasználó rossz funkciót használt a tokenek intelligens szerződésekhez történő elküldéséhez, és végleg elveszítette a tokenjeit!

Az Ethereum Alapítvány ismeri a hibát, de továbbra is népszerűsíti az ERC 20 szabványt. Nem tudom az okaikat ennek. Valószínűleg nem értékelik a kérdés importját, vagy ellenáll a változás.

Az ERC223 token szabvány: javasolt megoldás az ERC 20 hibára

A Reddit „Dexaran” felhasználónévvel rendelkező Ethereum fejlesztő javasolta az EIP 223 megoldását erre az ERC 20 hibára. Mielőtt összehasonlítanám az ERC 20 és az ERC 223 és az ERC 777 összehasonlítását, először elmagyarázom a javaslatát.

Az ERC223 token szabvány még mindig vázlat, és az Ethereum közösség még nem hajtotta végre. A következő megoldást javasolja:

  1. Eseménynek tekinti az Ethereum blokkláncon végrehajtott tranzakciót, és az „eseménykezelés” koncepciót használja.
  2. Ha a felhasználók az átviteli funkciót használják tokenek elküldéséhez intelligens szerződéshez, az hibát fog okozni, és ezt követően törli a tranzakciót.
  3. A felhasználó megfizeti az Ethereum „gázárát”, de nem veszít semmilyen tokent.
  4. Ez a javaslat további paramétert ad az „átutalás” funkcióhoz annak ellenőrzésére, hogy a fogadó cím szerződéses számla-e.
  5. Ha úgy találja, hogy a címzett címe szerződéses és nem EOA-fiók, akkor feltételezi, hogy a szerződés végrehajtott egy „tokenFallback”.
  6. A „tokenFallback” funkció lehetővé teszi a token visszahívását, így a tranzakció nem ír le tokent.

Míg az ERC223 jelentős mértékben megoldja az ERC 20 hibát, ebben a javaslatban gyengeségek vannak. Ha a címzett intelligens szerződés nem rendelkezik „tokanFallback” funkcióval, akkor a „Fallback” funkció fut, ami a tokenek elvesztését eredményezi.

Csak néhány projekt használja az ERC 223-at, erre példa AmigoCoin projekt. Az ERC 223 javaslatról további részleteket a GitHub EIP 223 adattár. Ezt a szabványt ERC 23-nak is nevezik.

ERC777 szabvány: továbbfejlesztett javaslat az ERC 20 hiba elhárítására

Az ERC 20 hibája miatt a tokenek elvesztésének megakadályozására szolgáló továbbfejlesztett javaslat az ERC 777 javaslata. A következőket tartalmazza:

  1. Új funkciók: „küldés” helyett „átvitel”, “authoriseOperator” helyett “jóváhagyás” és “tokensReceived” helyett “tokenFallback”.
  2. Az Ethereum platformnak addig volt hátránya, mert a fejlesztők nem tudták azonosítani, hogy az intelligens szerződések milyen funkciókat valósítanak meg. Az ERC 820, vagyis egy másik szabvány központi szerződési nyilvántartást vezetett be a hálózaton, így most már megismerhetők az intelligens szerződés funkciói és interfészei. Az ERC777 az intelligens szerződés által használt interfészek azonosítására használja. Most a fejlesztők előre tudni fogják, hogy a szerződés rendelkezik-e bizonyos funkciókkal elküldött tokenek fogadásához szükséges funkciókkal.
  3. Az ERC 777 lehetővé teszi az operátorok engedélyezőlistára tételét, így az Ethereum hálózat felhasználói most képesek lesznek elutasítani a fizetést a feketelistán szereplő címekről. Egy címet sok ok miatt lehet feketelistára tenni, pl. kísérlet a hálózat feltörésére, illegális tevékenységek története.

Az ERC 777 vs ERC 20 vs ERC 223 összehasonlításban láthatja, hogy az ERC777 hogyan kínál több lehetőséget a fejlesztőknek, hogy megakadályozzák a tokenek elvesztését. Az ERC777 szabvány azonban néhány kockázattal is jár, az alábbiak szerint:

  1. Az Ethereum egyes fejlesztői úgy vélik, hogy az „authoriseOperator” funkció elavult, ezért a fejlesztőknek nem szabad használniuk. Ehhez a funkcióhoz több „gázra” is szükség lesz, és ez további megterhelést jelent a hálózat számára.
  2. Az intelligens szerződések központi nyilvántartásának használata a szerződés által használt interfészek felkutatásához kockázatos. Lehet, hogy a központi nyilvántartásban vannak hibák, és bármi múlik rajta, negatív hatással lesz.

Az ERC777 még mindig vázlat, azonban az KARDSZÁRNYÚ DELFIN token használja. Olvassa el a javaslatot a EIP 777 GitHub adattár.

ERC 777 vs ERC 20 vs ERC 223: Fontos a pénzeszközök védelme

Bár csak az idő fogja megmondani, hogy az Ethereum ökoszisztéma melyik szabványt fogadja el „arany standardként”, Önnek, mint fejlesztőnek emlékeznie kell arra, hogy a kereskedők és a befektetők alapjainak védelme az Ön felelőssége. Ha ilyen felelős álláspontot képvisel, akkor valószínűleg egyet fog érteni abban, hogy a bonyolultság ellenére az ERC 777 szabványt végre kell hajtani és el kell fogadni.

Megjegyzés: Ha többet szeretne megtudni néhány kulcsfontosságú ERC-szabványról, olvassa el a „Tudnivalók az ERC-szabványok végső listája” című részt..

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
Adblock
detector
map