Îmi place că se fac mai multe cercetări în ceea ce privește confidențialitatea la nivel de RPC. Este o parte sub-cercetată și subapreciată a confidențialității Ethereum care merită o soluție. Din păcate, RPC-urile rotative nu sunt acea soluție, cel puțin în forma descrisă aici. Iată de ce 🧵
Idee simplă: un server între portofel și furnizorii RPC. Serverul folosește aleatoriu un RPC diferit pentru fiecare cerere. Rulați acest lucru într-un TEE 🔒! Cloud-ul nu vă vede cererile (atenție, tot metadate!) - iar RPC-ul nu vă vede IP-ul (îl vede pe cloud)
Problema 1: Niciun furnizor nu ar trebui să poată asocia adresa ta Ethereum cu adresa ta IP. Problema 2: Niciun furnizor nu ar trebui să poată asocia două dintre adresele tale Ethereum între ele. Deosebit de important în contextul discursurilor ascunse.
Prima soluție propusă nu rezolvă niciuna dintre probleme. De fapt, înrăutățește problema 1: în loc de un singur furnizor care vă cunoaște adresele IP și Ethereum, acum mai mulți astfel de furnizori le cunosc pe amândouă.
Văd două moduri de a implementa RPC-uri rotative: ➡️ 1. Implementați această funcționalitate direct în portofele. Avantaje 👍 •Repede •Dezavantajele 👎 • Acest lucru nu poate fi adaptat la niciun portofel, deoarece ar trebui implementat de fiecare dată. • **Mai important** RPC-urile văd în continuare IP-ul utilizatorului
A doua soluție rezolvă problema 1 prin introducerea unui middleware într-un TEE. Este în esență un proxy orb, pentru care orbirea este asigurată de TEE. Dar problema 2 rămâne nerezolvată: furnizorii pot asocia în continuare adresele tale Ethereum între ele.
Idee simplă: un server între portofel și furnizorii RPC. Serverul folosește aleatoriu un RPC diferit pentru fiecare cerere. Rulați acest lucru într-un TEE 🔒! Cloud-ul nu vă vede cererile (atenție, tot metadate!) - iar RPC-ul nu vă vede IP-ul (îl vede pe cloud)
TEE-urile nu sunt antiglonț. Dar chiar dacă presupunem că funcționează conform intenției, clientul trebuie totuși să verifice dacă middleware-ul cu care vorbește rulează de fapt într-un TEE. În caz contrar, clientul (portofelul) nu poate fi sigur că middleware-ul nu înregistrează de fapt totul.
Clientul poate verifica acest lucru efectuând un dans de atestare a sarcinii de lucru. Este posibil, dar complicat de implementat. Nu am văzut o implementare reală a acestui lucru în practică și nu îmi este clar dacă ar fi mai ușor de implementat decât simpla integrare a unui mixnet real.
Un proxy ar trebui să fie orb la ceea ce trece. Criptografia rezolvă acest lucru fără a fi nevoie de ipoteze de încredere TEE. Mixnet-urile precum Tor/Nym/HOPR funcționează astfel: Criptează sarcina utilă în mai multe straturi de criptare, unde fiecare hop decojește un strat de criptare de pe ceapă.
De ce nu sunt folosite mixnet-urile astăzi? - Utilizatorii nu cer confidențialitate la nivel RPC de la dezvoltatorii lor de portofele. Walletbeat rezolvă acest lucru. - Așteptări de <100ms RPC-uri UX. Mixnets/middleware adaugă latență. - Integrarea în portofelele de browser necesită reimplementarea TLS în JS pentru a cripta ultimul hop.
Mixnet-urile singure nu rezolvă problema 2. Problema rămâne că rotirea RPC-urilor naiv (furnizor aleatoriu la fiecare cerere) este de fapt mai rău pentru confidențialitate: înseamnă că mai mulți furnizori obțin o vizualizare a mai multor adrese în timp.
Soluție mai bună: pentru un RPC despre "adresă", trimiteți-l întotdeauna la furnizorul #'hash(address) modulo num_providers'. Cu alte cuvinte, interogările despre aceeași adresă merg la același furnizor RPC. Acest lucru asigură că niciun furnizor nu învață setul complet de adrese.
De asemenea, este mai bine să aveți mai mulți furnizori decât adrese. În acest fel, fiecare furnizor află fie una dintre adresele dvs., fie niciuna; niciodată mai mult. Dar adevărata soluție? - Rulează-ți propriul nod! - Cereți dezvoltatorului portofelului să înceapă să-i pese de confidențialitatea la nivel de RPC.
Lucruri pe care nu le-am acoperit, dar care contează: - Atacuri de corelație de sincronizare RPC. - Portofele care caută soldul mai multor adrese într-un singur RPC. - Solicitări non-Ethereum care scurg date similare. Portofelele de astăzi sunt pline de acestea; întreabă-mă de unde știu. - L2 cu puncte finale centralizate. (lol)
Chiar dacă acest subiect pare critic față de munca lui @jimouris, vreau să subliniez că nu este intenționat ca un dunk. Respect foarte mult pe oricine face un pas înainte pentru a aborda această problemă. Acest lucru este puțin cercetat și necesită mai multă atenție, așa că este încurajator să vezi oameni care lucrează la el.
Afișare original
3,1 K
25
Conținutul de pe această pagină este furnizat de terți. Dacă nu se menționează altfel, OKX nu este autorul articolului citat și nu revendică niciun drept intelectual pentru materiale. Conținutul este furnizat doar pentru informare și nu reprezintă opinia OKX. Nu este furnizat pentru a fi o susținere de nicio natură și nu trebuie să fie considerat un sfat de investiție sau o solicitare de a cumpăra sau vinde active digitale. În măsura în care AI-ul de generare este utilizat pentru a furniza rezumate sau alte informații, astfel de conținut generat de AI poate să fie inexact sau neconsecvent. Citiți articolul asociat pentru mai multe detalii și informații. OKX nu răspunde pentru conținutul găzduit pe pagini terțe. Deținerile de active digitale, inclusiv criptomonedele stabile și NFT-urile, prezintă un grad ridicat de risc și pot fluctua semnificativ. Trebuie să analizați cu atenție dacă tranzacționarea sau deținerea de active digitale este adecvată pentru dumneavoastră prin prisma situației dumneavoastră financiare.