A kriptoadatvédelem legnagyobb hibái
Általánosságban elmondható, hogy a felhasználói adatvédelem ellentétes a nyilvános blokkláncok természetével. A nyilvános főkönyv működéséhez bizonyos tranzakciós adatokat meg kell osztani a node-okkal és a hálózat résztvevőivel. Az ilyen rendszerek gyors online üzembehelyezését egyszerűen úgy oldható meg, hogy alapértelmezés szerint mindent nyilvánossá tesznek.
Ez az átláthatóság azonban a felhasználók szempontjából kitettséget jelent a felügyeletnek, a kényszerítésnek és az olyan nem szándékolt következményeknek, mint a kereskedési jelek kiszivárgása. Ez kereskedelmileg életképtelen és a saját sorsunk meghatározásához való jogunkat rontja. A valódi önrendelkezés nem létezhet, ha a felhasználók nem rendelkeznek az adataik felett; az adatvédelem a felhasználók szabadságának visszaállításáról szól, hogy szabadon dönthessenek arról, mit tesznek és mit nem tesznek közzé a külvilág számára.
Íme hét végzetes hiba, amely a kriptoszektor adatvédelmi törekvéseit tönkreteszi:
1. Centralizált rendszerek
Egy decentralizált világban a központosítás lustaság. Egyszerűbb (gyorsabb és olcsóbb) egy főkönyvet egy bank belső SQL-adatbázisán futtatni, mint tranzakciókat küldeni még a legnagyobb teljesítményű blokkláncokon is.
A decentralizáció azonban egyenlő a rugalmassággal. Ez az oka annak, hogy a kriptovalutáknak piaci értéke van. Enélkül a felhasználók jobban járnának már inkább a központosított intézmények által kínált sebességgel és költségmegtakarítással.
Ez még fontosabb az adatvédelmi protokollok esetében, ahol a centralizáció azt jelenti, hogy a fejlesztők kiváltságos hozzáférést biztosítanak maguknak a felhasználók adataihoz.
A protokollok készítői soha nem adhatnak maguknak olyan admin kulcsokat, amelyekkel befagyaszthatják vagy deanonimizálhatják a felhasználókat.
Egy másik központosítási vektor a multi-sig küszöbértékek, különösen a nem biztonságos hidak megkerülésére törekvő protokollok esetében. Még ha „megfelelően” is van beállítva, egy 3/5-ös multi-sig vitathatatlanul rosszabb a bizalmi feltételezések tekintetében, mint bármelyik bank.
És ha a multi-sig nem megfelelően van beállítva….
2. A logolás iránti vágy
Az adatvédelmi eszközöknek minden intézkedést meg kell tenniük annak érdekében, hogy ne lehessen nyomon követni a felhasználói tevékenységet, különösen a személyazonosításra alkalmas adatokat, például az IP-címeket és a böngészési tevékenységet.
Az adatvédelmi protokollokat olyan mindenre kiterjedő filozófiával kell megtervezni, amely csak a pillanatnyi ítélőképesség hiányát használja fel a felhasználók deanonimizálására.
Például a Railway Wallet (amely integrált RAILGUN adatvédelmi technológiát tartalmaz) alapértelmezés szerint minden felhasználó számára proxyt biztosít az RPC-hívásokhoz, így még ha valaki nem is használ VPN-t (amit kellene ?), az IP-je nem szivárog ki az RPC-csomópontokhoz.
3. Titkosított állapot
Miért ne lehetne az egész rendszer privát? Csábító… de a teljesen titkosított állapot bizonyos szempontból ugyanolyan nem kívánatos, mint a teljesen nyilvános.
A titkosított állapot egy fekete dobozt hoz létre, ahol a felhasználók és a megfigyelők nem tudják, mit csinál a dApp. Megszünteti a blokkláncok legjelentősebb biztonsági jellemzőjét: a nyilvános ellenőrizhetőséget.
Ha a dApp privát, hogyan lehet ellenőrizni, hogy a gazdaság és a szereplők helyesen járnak-e el? Hogyan reagálsz megfelelően egy támadásra vagy rosszindulatú tevékenységre, ha nem tudod, hogy történt-e valami?
A felhasználói adatvédelem jó – és a protokoll átláthatósága is.
4. Függés az egyes gyártóktól
A „bizalommentesség” azt jelenti, hogy nem kell bíznod egy harmadik félben (azaz egy vállalatban, ügynökben vagy bankpénztárosban), hogy a protokoll működik. A zero knowledge alapú titkosítás erőssége, hogy kevesebb függőséget teremt, beleértve a gyártóktól való függőséget is.
Gondoljunk például arra, ha olyan adatvédelmi rendszert hoznak létre, amely az Intel által a CPU-ikba épített Software Guard Extensions-ra támaszkodik. A rendszer biztonsága egy potenciális egyetlen hibaponton múlik: azon, hogy az Intel helyesen implementálta-e a termékét.
Az Intelt arra ösztönzik, hogy megfelelően járjon el, de az SGX-re való támaszkodás állandó sebezhetőséget és szükségtelen bizalmi feltételezést teremt. Vannak a gatekeeping-by-design megfontolások is, mivel az SGX speciális hardvert igényel, amely viszonylag drága és nehezen karbantartható. Ezzel szemben a a proof-of-stake validátor egy Raspberry Pi-n is futtatható.
5. Szélhámoskodás
A kriptovaluták védelme egy meggyőző narratíva, de ez nem elég erős értékjavaslat ahhoz, hogy egy teljesen új blokklánc vagy rollup építését indokolja (kivéve, ha a speciális lánc szigorú technikai innovációt hoz).
Az adatvédelmi rendszerek akkor a leghatásosabbak, ha olyan láncokon állnak rendelkezésre, ahol felhasználók és pénzügyi tevékenység létezik. Jobb híján a DeFi az Ethereum, az EVM és néhány más környezet, például a Solana körül gyűlt össze. A Solidity a király, és ezért részesült a biztonsági kutatások előnyeiből.
Egy újszerű végrehajtási környezet felpörgetése és a fejlesztők és felhasználók elcsábítása időt és gyakran fenntarthatatlan ösztönzőket igényel. Eközben több milliárd dollárnyi érték már most is a nyilvános láncokon ül, amelyeknek kétségbeesetten szükségük van az adatvédelemre.
A dedikált adatvédelmi láncok további biztonsági kérdéseket is felvetnek, például a hidak igénybevételét – amelyekről újra és újra bebizonyosodott, hogy a blokklánchálózatok legkevésbé biztonságos elemei. További aggályok közé tartozik a konszenzus, az érvényesítés és a szekvenciák központosítása.
6. Fejlesztések komplexitása
A fejlesztőkről gyakran azt gondolják, hogy zsenik (és néhányan azok is). A kriptográfia azonban elég bonyolult ahhoz, hogy a fejlesztőket arra kényszerítsék, hogy megtanuljanak és használjanak egy saját nyelvet, eszköztárat vagy ökoszisztémát, ami szükségtelenül bonyolult és kontraproduktív.
Az olyan nyelveken, mint a Solidity vagy a Vyper programnyelveken írt szerződések áthordozhatóak az EVM-et támogató hálózatok között. A Rust és más WebAssembly láncok esetében ez nem így van. Mindegyiknek saját szabványai vannak a futásidőre vonatkozóan. A fejlesztők szempontjából ez azt jelenti, hogy minden lánc számára külön szerződéses kódbázisokat kell fenntartani, annak ellenére, hogy ugyanazt a nyelvet használják.
Ennek eredményeképpen a termék kevésbé hozzáférhető.
7. Éretlen technológia
A „Varázslatos internetpénz” egy valóban kiváló mém. A kriptofejlesztők azonban olyan pénzügyi technológiát építenek, amelynek valós következményei vannak, és valódi pénzt kezel.
Az adatvédelmi technológiának kettős feladata van: figyelembe kell vennie a „pénz valódiságát” és magát az „adatvédelmet” – azaz biztonságosnak kell lennie a pénzügyi kizsákmányolásokkal ÉS mindennel szemben, ami a felhasználókat deanonimizálhatja. A technológiával kapcsolatos jelentős mennyiségű tudományos kutatás nem véletlenül létezik.
Különösen az adatvédelmi technológiákat kell harcban tesztelni és átgondolni, a biztonsági cégek átfogó auditjaival, a személyes adatok védelmezőinek értékeléseivel, a fehér kalaposok által végzett penetrációs tesztekkel stb.
Máskülönben hogyan várhatjuk el az emberektől – különösen a remélt új, mainstream felhasználóktól -, hogy kockáztassák identitásukat és pénzüket egy komplex technológiai platformon?
Konklúzió
A nyilvános blokkláncok „dox-by-design” elvet követik. Nem könnyű feladat a láncon belüli adatvédelmi rendszereket kiépíteni, miközben meg kell őrizni azokat az okokat, amelyek miatt a kriptográfia használata egyáltalán indokolt, mint például az ellenőrizhetőség és a decentralizáció.
A kiválasztott adatvédelmi eszköz adatvédelmi szintjének értékeléséhez nagyszerű forrás a Web3 Privacy Now kezdeményezés, amely kategorizálta és pontozta a különböző kripto adatvédelmi eszközöket.
Minotaurus (MTAUR) – A Kihagyhatatlan Előértékesítés!
- Akár 70% Kedvezmény a Tokenvásárlás Után
- Ajánlói Program és Ösztönző Juttatások
- 100 000 USDT Nyereményjáték: Kiemelkedő Nyerési Esély
- In-Game Hasznosság a 14.78 Mrd. USD Alkalmi Játék Piacon
- A SolidProof és a Coinsult Által Auditált Okosszerződés
