Linia care mi-a schimbat întreaga funcționalitate nu a fost într-un circuit de probă. A fost în documentele de ajutor. Midnight spune că pathForLeaf() este preferabil deoarece findPathForLeaf() necesită un scan O(n). Asta pare mic până când îți dai seama ce înseamnă pentru o aplicație reală. Pe Midnight, un flux de membru privat poate rămâne criptografic corect și totuși să devină mai greu de fiecare dată când aplicația uită unde a plasat inițial frunza.
Aceasta nu este o detaliu secundar. Este parte din produs.
Documentele Midnight fac mecanismul suficient de clar. Un contract Compact poate utiliza MerkleTreePath pentru a dovedi apartenența într-un MerkleTree fără a dezvălui care intrare s-a potrivit. Ținta JavaScript oferă constructorilor apoi două moduri diferite de a recupera calea din obiectul de stare: pathForLeaf() și findPathForLeaf(). Documentele spun că pathForLeaf() este mai bun atunci când este posibil. Motivul este direct. findPathForLeaf() trebuie să caute, iar căutarea este O(n). Problema este că pathForLeaf() funcționează doar dacă aplicația știe încă unde a fost inițial inserat elementul.
Aceasta este partea pe care nu cred că suficient de multe persoane o vor evalua.
Multă scriere despre criptografie tratează confidențialitatea ca și cum dovada ar fi întreaga bătălie. Midnight face ca asta să fie prea simplu. Da, utilizatorul poate dovedi membralitatea în mod privat. Da, contractul o poate verifica fără a expune care frunză s-a potrivit. Dar aceasta este doar jumătate din caracteristică. Cealaltă jumătate este recuperarea. Aplicația trebuie să producă în continuare calea. Dacă a păstrat o memorie bună de plasare sau indexare, fluxul privat rămâne curat. Dacă nu a făcut-o, caracteristica începe să se bazeze pe căutare.
Dovada rămâne elegantă. Produsul devine mai greu.
Cel mai curat mod de a o vedea este cu o listă de permisiuni private. Imaginează-ți o aplicație Midnight care permite utilizatorilor aprobați să acceseze ceva fără a dezvălui care intrare exactă din lista de permisiuni le aparține. Pe hârtie, asta sună ca o victorie frumoasă în privința confidențialității. În practică, aplicația trebuie să recupereze calea Merkle de fiecare dată când utilizatorul trebuie să dovedească membralitatea. Dacă sistemul a stocat pozițiile frunzelor cu atenție, acel flux rămâne strâns. Dacă nu a făcut-o, aplicația trebuie să caute din nou frunza. Acum caracteristica de confidențialitate nu mai este doar un sistem de dovadă. Este o problemă de disciplină a memoriei.
Aceasta este o povară foarte diferită de ceea ce se așteaptă majoritatea oamenilor.
Pe un lanț public, suntem obișnuiți să întrebăm dacă starea este vizibilă și dacă dovada este validă. Midnight adaugă o altă întrebare. Își amintește aplicația suficient despre propria stare privată pentru a face recuperarea dovezii ieftină? Acolo devine mult mai mult decât o notă de subsol de performanță. Midnight poate ascunde care membru s-a potrivit. Totuși, nu poate salva o aplicație neglijentă de la a uita unde a pus acel membru în primul rând.
Compensarea este reală. Confidențialitatea bazată pe Merkle a Midnight oferă constructorilor o modalitate de a păstra intrarea corespunzătoare ascunsă. Acesta este câștigul. Prețul este că aplicația poate necesita păstrarea unei structuri suplimentare în jurul datelor private dacă vrea ca funcția să pară fluidă. Documentele nu spun că confidențialitatea eșuează dacă aplicația uită frunza. Ele spun că recuperarea devine mai costisitoare. Acea diferență contează. Sistemul funcționează în continuare. Dar "funcționează în continuare" nu este același lucru cu "încă se simte suficient de bine pentru a fi folosit repetat."
Asta este unde constructorii pot fi prinși.
O echipă poate privi partea Compact, vede dovezi valide de membru și crede că funcția de confidențialitate este completă. Nu este completă. Nu dacă obiectul de stare de pe partea JS trebuie să recupereze căile eficient. Nu dacă produsul se așteaptă ca verificările private să aibă loc frecvent. Nu dacă arborele crește suficient de mare încât scanarea să nu mai pară inofensivă. La acel moment, ceea ce părea a fi o caracteristică curată de confidențialitate începe să depindă de faptul că cineva a tratat plasarea frunzelor ca fiind un stat de aplicație durabil în loc de gunoi temporar de implementare.
Acest cost nu se distribuie uniform.
Constructorul plătește primul, pentru că trebuie să decidă dacă locația frunzei este parte din modelul real al aplicației. Echipa de infrastructură plătește următoarea, pentru că trebuie ca recuperarea să rămână suficient de rapidă încât membralitatea privată să se comporte în continuare ca o caracteristică și nu ca o soluție lentă. Utilizatorul plătește ultimul, pentru că nu-i pasă dacă întârzierea a venit din logica elegantă Merkle sau din indexarea slabă. Ei văd doar că acțiunea privată se simte mai grea decât ar trebui.
De aceea nu cred că „dovada verifică” este un standard de revizuire complet pentru o aplicație Midnight. Vreau să știu cum se recuperează calea. Vreau să știu dacă aplicația a fost construită în jurul pathForLeaf() sau dacă se bazează tăcut pe findPathForLeaf() și acceptă costul scanării ca parte normală a caracteristicii. Acestea nu sunt alegeri cosmetice de implementare. Ele conturează dacă confidențialitatea Merkle rămâne practică odată ce aplicația părăsește etapa de demonstrație.
Părerea mea este simplă acum. Pe Midnight, membralitatea privată nu depinde doar de secret. Depinde de plasarea amintită. Arborele ascunde membrul. Aplicația trebuie să-l găsească încă. Dacă aplicația încetează să urmărească frunzele bine, sistemul de dovadă nu se prăbușește. Se întâmplă ceva mai enervant. Confidențialitatea se transformă într-o căutare, iar utilizatorul începe să plătească pentru o problemă de memorie pe care nu ar fi trebuit să o vadă niciodată.
@MidnightNetwork $NIGHT #night
