Buying Guides

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.

https://www.youtube.com/watch?v=videoseries

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button