A Zcash elhatárolódott a ZRC-20-tól és a CASH tokentől

A szervezet későbbi közleménye szerint azonban sem a ZRC-20-ról, sem a CASH tokenről nem rendelkezett előzetes információval, és egyik sem része a Zcash protokoll hivatalos fejlesztési folyamatának. A történet rámutat egy fontos kriptopiaci problémára is: attól, hogy egy új token vagy alkalmazás egy ismert blokkláncra épül, még nem válik automatikusan az adott hálózat hivatalos termékévé.

A Zcash Foundation szerint a ZRC-20 nem hivatalos fejlesztés

A Zcash Foundation közlése szerint a ZRC-20 és a CASH token egy független harmadik fél fejlesztése, amely sem szervezetileg, sem technológiai irányítás szempontjából nem kapcsolódik hivatalosan a Foundationhöz. A nonprofit szervezet azt is jelezte, hogy csak akkor szerzett tudomást a projektről, amikor az ügy nyilvánosan megjelent.

A félreértés alapját egy, a Zcash Foundation X-fiókjáról közzétett poszt adta, amely azt állította, hogy a Zcash „saját tokenstandardot kapott”. A bejegyzés a ZRC-20-at olyan rendszerként mutatta be, amellyel felhasználók tokeneket hozhatnak létre, bocsáthatnak ki és mozgathatnak a Zcash hálózatán, miközben a CASH tokent az első ilyen eszközként említette.

A későbbi hivatalos reakció ennek éppen az ellenkezőjét hangsúlyozta. A Foundation szerint a ZRC-20-at nem a Zcash fejlesztői készítették, nem hagyták jóvá, és nem is része a hálózat hivatalos konszenzusszabályainak.

A szervezet ezért arra kérte a felhasználókat, hogy alapos saját kutatást végezzenek, mielőtt kapcsolatba lépnek a ZRC-20 rendszerrel vagy a CASH tokennel.

Nem tudni, hogyan került ki a félrevezető poszt

Az incidens egyik legérdekesebb kérdése, hogy miként kerülhetett egy független tokenprojekt promóciós anyaga a Zcash Foundation hivatalos közösségi médiafiókjára. Erre egyelőre nincs nyilvánosan megerősített magyarázat.

Fontos ugyanakkor, hogy bizonyíték hiányában nem lehet biztosan fiókfeltörésről vagy hackről beszélni. Az ilyen következtetéshez a Foundation hivatalos megerősítése, technikai vizsgálata vagy más ellenőrizhető információ szükséges.

A ZRC-20 mögött álló csapat kiléte szintén nem teljesen átlátható. A projekt technikai dokumentációt és promóciós oldalakat publikált, de a nyilvánosan hozzáférhető anyagok alapján nem derül ki egyértelműen, mely cég, jogi személy vagy név szerint azonosítható fejlesztői csapat működteti a rendszert.

Ez a bizonytalanság különösen fontos egy új tokenstandard és token esetében. A felhasználók számára ugyanis nemcsak az a lényeg, hogy technikailag működik-e egy rendszer, hanem az is, hogy ki felel érte, milyen szabályok szerint működik, és kihez lehet fordulni probléma esetén.

Így működne a ZRC-20

A projekt technikai dokumentációja szerint a ZRC-20 egy kísérleti, helyettesíthető tokenekhez készült specifikáció. A rendszer a Zcash privát, úgynevezett shielded tranzakcióinak memo mezőjében tárolna strukturált utasításokat.

A működés alapja az lenne, hogy ezekbe a titkosított memo mezőkbe JSON formátumú adatokat írnak, majd külön indexelő szoftverek olvassák ki és dolgozzák fel azokat. Ezek az indexerek a blokkok sorrendjében értelmeznék az utasításokat, és ennek alapján számolnák ki, hogy melyik felhasználónak mennyi tokenje van.

A dokumentáció három alapműveletet ír le: token létrehozása, token kibocsátása és token átruházása. A „deploy” művelet létrehozná a tickernevet és meghatározná a maximális kínálatot, a „mint” új tokenegységeket bocsátana ki a megadott limitig, a „transfer” pedig az egyenlegek közötti mozgást kezelné.

A rendszer koncepciója több ponton hasonlít a Bitcoin BRC-20 megoldásához. A fő különbség az adattárolás módja: míg a BRC-20 Bitcoin-inscriptionökre épül, a ZRC-20 a Zcash shielded kimeneteinek 512 bájtos memo mezőjét használná.

Nem lenne valódi Zcash-protokollfrissítés

A ZRC-20 egyik legfontosabb technikai sajátossága, hogy működéséhez nem lenne szükség a Zcash konszenzusszabályainak módosítására. Ez azt jelenti, hogy a Zcash node-ok nem ismernék fel külön tokenműveletként a ZRC-20 utasításokat.

A hálózat csak a mögöttes Zcash-tranzakciókat ellenőrizné és véglegesítené. A tokenegyenlegek nyilvántartását, a kibocsátást és a transzfereket egy külső indexelő réteg kezelné.

Ez nagyon fontos különbség. Attól, hogy a ZRC-20 a Zcash tranzakcióit használja adattovábbításra, még nem válik a Zcash protokoll natív tokenfunkciójává.

A CASH token egyenlegei tehát nem a Zcash konszenzusában léteznének, hanem olyan szoftverekben, amelyek követik a ZRC-20 által meghatározott külön szabályokat. Ha két indexer eltérően értelmezi ezeket a szabályokat, elméletileg eltérő egyenlegeket is számolhatnak.

A privát tranzakciók sem jelentik automatikusan a tokenek privátságát

A Zcash legismertebb tulajdonsága a shielded tranzakciós rendszer, amely fejlett kriptográfiai módszerekkel képes elrejteni bizonyos tranzakciós adatokat. Emiatt könnyű lenne azt feltételezni, hogy egy Zcashre épülő tokenstandard automatikusan privát tokeneket hoz létre.

A ZRC-20 dokumentációja szerint azonban ez nem ilyen egyszerű. Ahhoz, hogy az indexerek kiszámítsák a tokenegyenlegeket, hozzá kell férniük a memo mezőkben szereplő utasításokhoz.

Az egyik javasolt megoldás egy közös protokollcím használata, amelynek bejövő viewing key-jét nyilvánossá tennék. Ez lehetővé tenné, hogy az indexelő szoftverek dekódolják a tokenműveleteket, miközben a tranzakció más részei továbbra is shielded állapotban maradhatnak.

Ez azt jelenti, hogy a ZRC-20 tokenek adatvédelmi tulajdonságai nem azonosak automatikusan a Zcash natív ZEC tranzakcióinak privát működésével. A végső adatvédelmi szint jelentős részben attól függne, hogyan valósítják meg az indexelést és a tokenműveletek feldolgozását.

Külön aláírásokra lenne szükség

A shielded Zcash-címek egyik sajátossága, hogy a nyilvános blokkláncadatokból nem feltétlenül állapítható meg, ki hozta létre az adott kimenetet. Ez tokenes rendszer esetében problémát jelent, mert a protokollnak valamilyen módon hitelesítenie kell, ki jogosult egy adott tokenegyenleg mozgatására.

A ZRC-20 tervezete ezért külön account azonosítókat és Ed25519 digitális aláírásokat használna. Ezek az aláírások a tokenművelet payloadjába kerülnének, és az indexelő réteg ellenőrizné őket.

Más szóval a token tulajdonjogának hitelesítése részben egy külön logikai rétegen történne, nem közvetlenül a Zcash natív címstruktúráján keresztül. Ez további technikai komplexitást visz a rendszerbe.

Az ilyen megoldás működhet, de fontos látni, hogy már egy új, önálló protokollrétegről beszélünk. Ennek biztonságát, implementációját és szabályait külön kell vizsgálni a Zcash alaprétegétől.

Több fontos részlet még nincs megoldva

A ZRC-20 dokumentáció maga is számos nyitott kérdést felsorol. Ezek között szerepel például az atomikus kereskedés, az 512 bájtnál nagyobb payloadok kezelése, a strukturált memo-formátum és az esetleges névütközések problémája.

Az atomikus kereskedés különösen fontos kérdés. Ez olyan mechanizmust jelent, amelyben két eszköz cseréje vagy teljes egészében végbemegy, vagy egyáltalán nem történik meg, így egyik fél sem kerülhet olyan helyzetbe, hogy átadta saját eszközét, miközben a másik oldalt nem kapta meg.

A jelenlegi tervezet nem tartalmaz ilyen natív mechanizmust. Emiatt a korai ZRC-20 piacterek valószínűleg központosított vagy letétkezelő jellegű rendszerekre lennének utalva.

Ez új partnerkockázatot teremt. Ha a kereskedést egy központi szereplő közvetíti, akkor a felhasználóknak annak működésében, biztonságában és fizetőképességében is meg kell bízniuk.

Az „official” és a „Zcashre épül” nem ugyanaz

A Zcash hivatalos protokollfejlesztése a Zcash Improvement Proposal, vagyis ZIP rendszeren keresztül történik. Ez egy formális folyamat, amelyben fejlesztési javaslatok készülnek, technikai részleteket publikálnak, közösségi visszajelzéseket gyűjtenek, és dokumentálják a hálózatot érintő tervezési döntéseket.

A ZRC-20 nem jelenik meg elfogadott protokollfunkcióként ebben a folyamatban. Ez önmagában nem jelenti azt, hogy technikailag használhatatlan, viszont egyértelművé teszi, hogy nem tekinthető hivatalosan elfogadott Zcash-tokenstandardnak.

Bármely külső fejlesztő használhatja a Zcash tranzakciós infrastruktúráját olyan alkalmazás építésére, amely nem igényli a hálózat konszenzusának módosítását. Ehhez nincs feltétlenül szükség a Foundation jóváhagyására.

A fontos különbség tehát az, hogy egy alkalmazás „Zcashre épülhet” úgy is, hogy közben sem a Zcash Foundation, sem a hálózat fejlesztői nem támogatják, nem auditálták és nem hagyták jóvá.

A ZRC-20 név önmagában is félreérthető lehet

További zavart okozhat, hogy a ZRC-20 elnevezés nem kizárólag ehhez a mostani projekthez kapcsolódik. A ZetaChain már használja a ZRC-20 nevet saját omnichain fungible token szabványára.

A Zcash közösségében korábban szintén felmerült hasonló elnevezés, amikor arról folyt vita, hogy egy tokenfunkció miként növelhetné a hálózati aktivitást és a ZEC felhasználási lehetőségeit. Ezek a beszélgetések azonban nem jelentik azt, hogy a jelenlegi ZRC-20 projekt hivatalos vagy történetileg folytonos folytatása lenne ezeknek az elképzeléseknek.

A névegyezés ezért könnyen téves asszociációt kelthet. A kriptopiacon általában is fontos figyelni arra, hogy egy ismert szabványhoz hasonló elnevezés önmagában nem bizonyít hivatalos kapcsolatot vagy kompatibilitást.

A hivatalos Zcash-fejlesztések máshol zajlanak

Miközben a ZRC-20 körül kialakult a vita, a Zcash hivatalos fejlesztési iránya más területekre koncentrál. A tervezett NU7 hálózati frissítéshez több olyan javaslat is kapcsolódik, amelyek közvetlenül a Zcash protokoll működését módosítanák.

Ezek között szerepelt például a blokkidő 75 másodpercről 25 másodpercre történő csökkentése. Egy ilyen változtatás gyorsabb blokkgenerálást tenne lehetővé, miközben a blokkjutalmakat úgy kellene módosítani, hogy a ZEC kibocsátási üteme összességében ne változzon.

Az ilyen fejlesztések lényegesen eltérnek egy külső indexelő rendszerre épülő tokenprojekttől. A hálózati szintű módosításokhoz fejlesztői koordinációra, node-üzemeltetői támogatásra és szélesebb közösségi egyeztetésre van szükség.

Éppen ezért fontos a Foundation mostani figyelmeztetése. A felhasználók könnyen összekeverhetik egy külső projekt technológiai kísérletét egy hivatalos protokollfrissítéssel, pedig a kettő jogi és technikai szempontból is teljesen más kategória.

Az amerikai tokenvásárlók számára külön kockázatot jelent a kibocsátó kiléte

Az Egyesült Államokban egy harmadik fél által kibocsátott token jogi megítélése nem attól függ, hogy milyen blokkláncra épül. Sokkal fontosabb lehet, hogyan bocsátják ki, hogyan értékesítik, milyen ígéreteket kapcsolnak hozzá, és milyen jogokat kapnak a vásárlók.

A közelmúlt amerikai szabályozási javaslatai külön is foglalkoznak bizonyos digitális eszközökhöz kötődő befektetési konstrukciókkal. Ezek a keretek potenciálisan különböző könnyítéseket vagy követelményeket biztosíthatnak a kisebb kibocsátások számára, de minden esetben lényeges a kibocsátó azonosíthatósága és a token értékesítésének módja.

A CASH token jogi státuszát semmilyen amerikai szabályozó nem minősítette hivatalosan a megadott információk alapján. Emiatt nem lehet biztosan kijelenteni, hogy értékpapírnak, árucikknek vagy más kategóriának minősülne.

A bizonytalanságot növeli, hogy a projekt mögött álló szervezet kiléte sem teljesen világos. Egy új token esetében ez különösen nagy kockázatot jelenthet, mert a befektetők számára nehezebbé válik annak megítélése, hogy ki felel a kibocsátásért és milyen jogi kötelezettségeket vállal.

ZEC közben extrém volatilitást mutat

A Foundation figyelmeztetése egy olyan időszakban érkezett, amikor a ZEC árfolyama önmagában is rendkívül erős mozgásokat mutatott. A token szeptember első hetében mintegy 43%-ot emelkedett, és 1200 dollár közelébe került, miután áttörte az 1000 dolláros szintet.

Néhány nappal később azonban már 1139 dollár környékére korrigált, miután korábban 1290 dollár közelében többéves csúcsot ért el. A visszaesés során a futures nyitott kötésállomány mintegy 20%-kal csökkent egyetlen nap alatt, és hozzávetőleg 17,2 millió dollárnyi long pozíciót likvidáltak.

Szeptember 16-án ismét gyors fordulat következett. A ZEC több mint 20%-ot erősödött, megközelítette az 1337 dollárt, napközben pedig 1385 dollár közelében is járt.

A mozgást részben a NU7 fejlesztési folyamat iránti megújult figyelem táplálta, miközben a kereskedők az 1375 és 1500 dollár körüli ellenállási szinteket figyelték.

Miért fontos különválasztani a ZEC-et és a CASH tokent?

A mostani történet egyik legfontosabb tanulsága, hogy a ZEC árfolyamának erősödése és a ZRC-20/CASH projekt megjelenése két külön történet. Attól, hogy egy külső projekt a Zcash blokkláncot használja, annak tokenje nem válik automatikusan a ZEC ökoszisztéma hivatalos részévé.

Ez a különbség azért is fontos, mert a kriptopiaci spekulációban gyakran egy erős narratíva elegendő ahhoz, hogy a befektetők gyorsan összekapcsoljanak egymástól független eseményeket. Egy tokenstandard megjelenése például könnyen azt a benyomást keltheti, hogy a hálózat hivatalosan bővült új funkcióval, pedig technikailag ez nem feltétlenül igaz.

A Zcash Foundation reakciója lényegében ezt a félreértést próbálja megelőzni. A szervezet azt hangsúlyozza, hogy a ZRC-20 és a CASH nem hivatalos Zcash-termékek, és a használatukhoz kapcsolódó kockázatokat a felhasználóknak külön kell értékelniük.

A történet legnagyobb kérdése továbbra is a bizalom

A ZRC-20 technikai elképzelése önmagában érdekes kísérlet. A rendszer megpróbál egy fungible token réteget építeni a Zcash fölé úgy, hogy közben ne legyen szükség natív smart contractokra vagy konszenzusmódosításra.

A gyenge pont éppen ebből fakad. A tokenegyenlegek nem a Zcash protokollban élnek, hanem egy külső indexelő logikától függenek, amelynek szabályait, üzemeltetőit és implementációját a felhasználóknak külön kell megbízhatónak találniuk.

A projekt mögötti szervezet korlátozott átláthatósága és a Foundation fiókján keresztül megjelent, később elutasított promóciós poszt tovább növeli a bizonytalanságot. Egyelőre tehát a technológiai lehetőség mellett legalább ilyen hangsúlyos a bizalmi kockázat.

A Zcash Foundation figyelmeztetése ezért jóval többről szól egyetlen tokenvitánál. Arra emlékeztet, hogy a blokklánc nyílt infrastruktúra: bárki építhet rá új terméket, de ettől az még nem válik hivatalossá, auditálttá vagy biztonságossá.

A felhasználók számára a legfontosabb különbség éppen ez. Egy projekt neve, logója vagy az ismert hálózathoz való technikai kapcsolódása nem helyettesíti a fejlesztői átláthatóságot, a hivatalos támogatást és a független ellenőrzést.