Pidän siitä, että RPC-tason yksityisyyttä tutkitaan enemmän. Se on alitutkittu, aliarvostettu osa Ethereumin yksityisyyttä, joka ansaitsee ratkaisun. Valitettavasti RPC:iden pyöriminen ei ole se ratkaisu, ainakaan tässä kuvatussa muodossa. Tässä syy 🧵
Yksinkertainen idea: palvelin lompakon ja RPC-palveluntarjoajien välillä. Palvelin käyttää satunnaisesti eri RPC:tä kullekin pyynnölle. Suorita tämä TEE:ssä 🔒! Pilvi ei näe pyyntöjäsi (varo, ne ovat edelleen metatietoja!) - ja RPC ei näe IP-osoitettasi (he näkevät pilven)
Ongelma 1: Yhdenkään palveluntarjoajan ei pitäisi pystyä yhdistämään Ethereum-osoitettasi IP-osoitteeseesi. Ongelma 2: Yhdenkään palveluntarjoajan ei pitäisi pystyä yhdistämään kahta Ethereum-osoitettasi toisiinsa. Erityisen tärkeää salamyhkäisten osoitteiden yhteydessä.
Ensimmäinen ehdotettu ratkaisu ei ratkaise kumpaakaan ongelmaa. Itse asiassa se pahentaa ongelmaa 1: sen sijaan, että yksi palveluntarjoaja tietäisi IP- ja Ethereum-osoitteesi, nyt useat tällaiset palveluntarjoajat tietävät ne molemmat.
Näen kaksi tapaa toteuttaa kiertäviä RPC:itä: ➡️ 1. Ota tämä toiminto käyttöön suoraan lompakoissa. Etuja 👍 •Nopea •Haitat 👎 • Tätä ei voi mukauttaa mihinkään lompakkoon, koska se on toteutettava joka kerta. • **Vielä tärkeämpää** RPC:t näkevät edelleen käyttäjän IP-osoitteen
Toinen ratkaisu ratkaisee ongelman 1 ottamalla väliohjelmiston käyttöön TEE:ssä. Se on pohjimmiltaan sokea välityspalvelin, jolle sokeuden tarjoaa TEE. Mutta ongelma 2 on edelleen ratkaisematta: palveluntarjoajat voivat silti yhdistää Ethereum-osoitteesi toisiinsa.
Yksinkertainen idea: palvelin lompakon ja RPC-palveluntarjoajien välillä. Palvelin käyttää satunnaisesti eri RPC:tä kullekin pyynnölle. Suorita tämä TEE:ssä 🔒! Pilvi ei näe pyyntöjäsi (varo, ne ovat edelleen metatietoja!) - ja RPC ei näe IP-osoitettasi (he näkevät pilven)
TEE:t eivät ole luodinkestäviä. Mutta vaikka olettaisimme, että ne toimivat tarkoitetulla tavalla, asiakkaan on silti varmistettava, että väliohjelmisto, jonka kanssa he puhuvat, toimii todella TEE:ssä. Muussa tapauksessa asiakas (lompakko) ei voi olla varma, että väliohjelmisto ei itse asiassa kirjaa kaikkea.
Asiakas voi varmistaa tämän suorittamalla työmäärän todentamistanssin. Se on mahdollista, mutta monimutkaista toteuttaa. En ole nähnyt tämän todellista toteutusta käytännössä, eikä minulle ole selvää, olisiko se helpompi toteuttaa kuin vain todellisen mixnetin integrointi.
Välityspalvelimen tulee olla sokea sille, mitä se kulkee. Kryptografia ratkaisee tämän ilman TEE-luottamusoletuksia. Mixnetit, kuten Tor/Nym/HOPR, toimivat näin: Salaa hyötykuorma useilla salauskerroksilla, joissa jokainen hyppy kuorii yhden salauskerroksen sipulista.
Miksi mixnettejä ei käytetä nykyään? - Käyttäjät eivät pyydä RPC-tason yksityisyyttä lompakon kehittäjiltä. Walletbeat korjaa tämän. - <100 ms RPC:n UX-odotukset. Mixnetit/väliohjelmistot lisäävät viivettä. - Integrointi selainlompakoihin edellyttää TLS:n uudelleenkäyttöönottoa JS:ssä viimeisen hypyn salaamiseksi.
Mixnetit eivät myöskään yksin ratkaise ongelmaa 2. Ongelmana on, että RPC:iden vaihtaminen naiivisti (satunnainen palveluntarjoaja jokaisessa pyynnössä) on itse asiassa huonompi yksityisyyden kannalta: se tarkoittaa, että useat palveluntarjoajat saavat näkymän useista osoitteistasi ajan myötä.
Parempi ratkaisu: RPC:lle 'address', lähetä se aina palveluntarjoajalle #'hash(address) modulo num_providers'. Toisin sanoen samaa osoitetta koskevat kyselyt menevät samalle RPC-palvelulle. Näin varmistat, että yksikään palveluntarjoaja ei saa tietää kaikkia osoitteitasi.
On myös parempi, että palveluntarjoajia on enemmän kuin osoitteita. Tällä tavalla jokainen palveluntarjoaja saa tietää joko yhden osoitteistasi tai ei yhtään; ei koskaan useita. Mutta todellinen ratkaisu? - Suorita oma solmu! - Pyydä lompakon kehittäjää huolehtimaan RPC-tason tietosuojasta.
Asioita, joita en käsitellyt, mutta joilla on myös merkitystä: - RPC-ajoituskorrelaatiohyökkäykset. - Lompakot, jotka etsivät useiden osoitteiden saldoa yhdestä RPC:stä. - Muut kuin Ethereum-pyynnöt, jotka vuotavat samanlaisia tietoja. Nykypäivän lompakot ovat täynnä niitä; kysy minulta, mistä tiedän. - L2:t keskitetyillä päätepisteillä. (lol)
Vaikka tämä ketju vaikuttaa kriittiseltä @jimouris työtä kohtaan, haluan korostaa, että sitä ei ole tarkoitettu donkiksi. Kunnioitan suuresti jokaista, joka todella ryhtyy puuttumaan tähän ongelmaan. Tätä on tutkittu liian vähän ja se vaatii enemmän huomiota, joten on rohkaisevaa nähdä ihmisten työskentelevän sen parissa.
Näytä alkuperäinen
3,1 t.
25
Tällä sivulla näytettävä sisältö on kolmansien osapuolten tarjoamaa. Ellei toisin mainita, OKX ei ole lainatun artikkelin / lainattujen artikkelien kirjoittaja, eikä OKX väitä olevansa materiaalin tekijänoikeuksien haltija. Sisältö on tarkoitettu vain tiedoksi, eikä se edusta OKX:n näkemyksiä. Sitä ei ole tarkoitettu minkäänlaiseksi suositukseksi, eikä sitä tule pitää sijoitusneuvontana tai kehotuksena ostaa tai myydä digitaalisia varoja. Siltä osin kuin yhteenvetojen tai muiden tietojen tuottamiseen käytetään generatiivista tekoälyä, tällainen tekoälyn tuottama sisältö voi olla epätarkkaa tai epäjohdonmukaista. Lue aiheesta lisätietoa linkitetystä artikkelista. OKX ei ole vastuussa kolmansien osapuolten sivustojen sisällöstä. Digitaalisten varojen, kuten vakaakolikoiden ja NFT:iden, omistukseen liittyy suuri riski, ja niiden arvo voi vaihdella merkittävästi. Sinun tulee huolellisesti harkita, sopiiko digitaalisten varojen treidaus tai omistus sinulle taloudellisessa tilanteessasi.