Il modo più chiaro in cui posso dirlo è questo: su Midnight, puoi rimuovere un elemento da un elenco privato e avere comunque passare una vecchia prova.
Quella era la linea di forza a cui continuavo a tornare mentre leggevo i documenti su MerkleTree e HistoricMerkleTree. Midnight dice che entrambi possono aiutare con l'appartenenza privata. Ma dice anche che HistoricMerkleTree.checkRoot può accettare prove contro versioni precedenti dell'albero. Questo è utile quando inserimenti frequenti altrimenti continuerebbero a rompere le prove. È anche il punto in cui un sistema di autorizzazione privata può iniziare a discostarsi dalle sue regole attuali. Se la tua app ha bisogno di revoca o sostituzione, una vecchia prova può continuare a vivere dopo che l'elenco è già cambiato.
Non è un piccolo caso limite. È una scelta di design con denti.
I documenti di Midnight sono in realtà molto chiari qui. Un MerkleTree normale ti consente di dimostrare l'iscrizione rispetto all'albero attuale senza rivelare quale elemento corrisponde. Un HistoricMerkleTree è diverso perché le vecchie radici possono rimanere utilizzabili. Questo dà continuità ai costruttori. Nuove inserzioni non costringono automaticamente tutti a ricostruire le prove immediatamente. Per alcuni prodotti, questo è un vero miglioramento. Impedisce al sistema di diventare fragile ogni volta che l'albero cresce.
Ma la stessa comodità diventa pericolosa nel momento in cui il prodotto dipende dalla verità attuale invece della verità storica.
Immagina un'app Midnight che utilizza l'iscrizione privata come un cancello. Forse è una lista di autorizzazione privata. Forse è una credenziale revocabile. Forse è un diritto che dovrebbe scomparire una volta che un record viene sostituito. L'utente non ha bisogno di rivelare quale voce esatta possiede. Midnight può proteggere questo. Va bene. Ma ora supponi che il costruttore abbia scelto HistoricMerkleTree, il record viene revocato e l'utente detiene ancora una prova da una versione precedente dell'albero. Il contratto on-chain non è diventato insicuro nel senso usuale. La prova può ancora verificare correttamente. Il fallimento è diverso. L'app voleva "vero ora." La struttura continua a onorare "vero prima."
Questo è il vero disallineamento.
Molti scritti di crypto trattano il successo della prova come la fine dell'argomento. Midnight lo rende troppo superficiale. Una prova può essere valida e l'app può ancora essere errata. La crittografia può funzionare esattamente come progettato mentre la regola del prodotto è già cambiata. Ecco perché questo non è solo una nota a piè di pagina di Merkle-tree. È un problema di temporizzazione delle regole che si nasconde dietro una scelta di archiviazione.
I documenti ammettono più o meno direttamente questo. Dicono che l'HistoricMerkleTree non è adatto se gli elementi vengono frequentemente rimossi o sostituiti, perché le vecchie prove possono ancora essere considerate valide quando non dovrebbero esserlo. Quella frase è importante. Ti dice che Midnight non sta vendendo un albero amichevole per la privacy come risposta universale. Sta dicendo ai costruttori di scegliere in base a come invecchiano le loro regole. Se le prove devono sopravvivere alle inserzioni, una struttura aiuta. Se le autorizzazioni devono morire velocemente, quella stessa struttura può diventare quella sbagliata.
Quella compensazione è più seria di quanto sembri inizialmente.
I costruttori spesso pensano di scegliere una rappresentazione di insieme privata. Su Midnight, stanno anche scegliendo una politica di revoca. Quella è la parte che penso molte persone perderanno. Un HistoricMerkleTree non risponde solo a "posso dimostrare questa iscrizione privatamente?" Risponde anche a "quanta storia sono disposto a far portare con sé questa prova?" In un sistema con molte inserzioni, questo può essere intelligente. In un sistema con molte revoche, può silenziosamente rendere l'app troppo indulgente.
E quel costo non ricade in modo uniforme.
Il costruttore paga per primo, perché deve capire se la propria app tiene più alla continuità della prova o alla freschezza della regola. Il revisore paga dopo, perché non può fermarsi a "questo utilizza un albero di iscrizione privata." Deve chiedere quale, e che tipo di finestra di validità crea. L'utente o la controparte paga per ultimo, perché potrebbe fidarsi di un controllo di autorizzazione privata che sembra attuale mentre in realtà onora stati precedenti.
Ecco perché non leggo questo come una discussione astratta sull'archiviazione. Lo leggo come semantica del prodotto.
I documenti di Midnight aiutano anche a spiegare perché questo sia così importante per contrasto. I valori del libro mastro ordinario e le operazioni Set sono pubbliche, quindi i costruttori si orientano verso strutture Merkle quando vogliono dimostrare l'iscrizione senza esporre il valore esatto. Questa è la vittoria della privacy. Ma una volta che ti sposti in alberi di iscrizione privati, la scelta smette di riguardare solo il nascondere il membro. Diventa una questione se la prova debba seguire l'ultima versione della regola o rimanere ancorata a versioni precedenti di essa.
È qui che il prodotto può diventare morbido senza sembrare rotto.
Il mio punto di vista è diretto ora. Su Midnight, l'iscrizione amichevole per la privacy non è la stessa cosa della verità nel presente. Se un costruttore utilizza HistoricMerkleTree in un'app con molte revoche, non sta solo scegliendo una struttura dati. Sta decidendo che la prova di ieri può continuare a parlare dopo che la regola di oggi è cambiata. La lista è cambiata. La prova non è morta con essa. Se l'app ha bisogno che la revoca significhi revoca, ciò non è eleganza. È la politica sbagliata che si nasconde dietro la giusta crittografia.
@MidnightNetwork $NIGHT #night
