Una demo del vault di privacy di Midnight necessita di firmatari esterni per rilasciare token Ethereum

I prelievi dal vault sperimentale di Ethereum della SIG Network richiedono la sua rete di firmatari, anche se gli asset sottostanti rimangono su Ethereum. L'esempio illustra la dipendenza dal prelievo nel piano di privacy Nightmode di Midnight: gli utenti bruciano una richiesta protetta prima che il trasferimento esterno venga firmato, e il recupero da un trasferimento fallito richiede anche una risposta attestata.

L'account di Charles Hoskinson @IOHK_Charles ha dato il benvenuto a Tron in Midnight il 21 ottobre. La roadmap della SIG prevede Tron per dicembre 2026, mentre l'integrazione di Ethereum elencata è sulla rete di test stagenet.

Come il vault di Ethereum detiene gli asset

SIG descrive il suo servizio come un contratto Midnight che ha un normale account Ethereum. Una soglia di firmatari produce la firma Ethereum quando il contratto la richiede. SIG afferma che i firmatari sono indipendenti e che nessun singolo firmatario può agire da solo.

In questa applicazione educativa e sperimentale, i token ERC20 sottostanti si trovano nell'account EVM del vault. Su Midnight, gli utenti detengono token di vault protetti che rappresentano le loro richieste su quel pool. Gli asset nativi che rimangono su Ethereum rispondono quindi a dove sono registrati gli asset; non rispondono, di per sé, a chi può farli muovere.

La distinzione spiega anche la combustione. Iniziare un prelievo distrugge la richiesta protetta che viene riscattata, piuttosto che distruggere l'ERC20 sottostante. Un pagamento esterno riuscito completa il riscatto. Se il pagamento riceve uno dei risultati di fallimento documentati, l'applicazione può ripristinare la richiesta.

Il walkthrough del prelievo tratta la spesa della moneta del titolare come autorizzazione. Il titolare fornisce una moneta di vault protetta che corrisponde al token e all'importo esatto del prelievo, quindi sceglie un indirizzo di destinazione. Il circuito rifiuta una destinazione zero.

Il circuito startWithdraw brucia quella moneta e mette in coda la richiesta. Un successivo flush della coda assegna il numero di sequenza della transazione dell'account del vault, noto come nonce. Il passo di invio registra quindi una richiesta per il trasferimento ERC20 esatto e notifica il servizio di firma MPC, o calcolo multiparte.

Il resto è una sequenza di responsabilità distinte:

Il servizio di firma non trasmette la transazione. L'app o il relayer la assembla con la firma verificata e la invia alla catena EVM.

Un trasferimento fallito e un servizio silenzioso sono diversi

Il servizio ha un secondo compito dopo la firma. Fornisce un'attestazione dell'esito della transazione esterna, separata dalla firma che ha autorizzato quella transazione. Il protocollo di integrazione descrive come legare quell'esito alla richiesta e ai suoi dati restituiti.

Il vault controlla l'attestazione rispetto alla sua chiave di risposta MPC configurata prima di consentire il regolamento.

La specifica di prelievo descrive tre modi in cui la richiesta può essere ripristinata: una transazione annullata, una transazione resa non valida perché un'altra ha consumato il suo nonce, o un trasferimento ERC20 eseguito che ha restituito falso. Dopo che il risultato attestato è stato messo in coda e svuotato, il prelevatore completa la richiesta e riceve un importo protetto riemesso.

Un trasferimento riuscito che restituisce vero mantiene il burn in atto e chiude la richiesta. Nel percorso di fallimento, il ripristino è una richiesta di vault su Midnight, piuttosto che un nuovo pagamento dell'asset nativo alla destinazione.

Il percorso di rimborso documentato richiede un'attestazione verificata e svuotata. Una richiesta di firma non risposta o una risposta mancante non soddisfa di per sé tale condizione.

L'esempio ha anche un meccanismo di emergenza nel codice del vault. Il deployer può avviare una richiesta di sostituzione del nonce per una transazione di vault bloccata, utilizzando un trasferimento a valore zero dall'account del vault a se stesso allo stesso nonce.

Lo scopo è rendere la transazione originale non valida, dopo di che un risultato attestato può supportare il suo insediamento di fallimento. L'avvio di questo recupero è riservato al deployer, sebbene l'invio di una richiesta già corretta sia senza permesso. È un'altra transazione firmata, seguita da attestazione, piuttosto che un'uscita che bypassa il servizio MPC.

Il codice porta anche un avviso specifico: sostituire una richiesta originale prima che l'MPC l'abbia firmata può competere con quella richiesta, potenzialmente lasciandola senza un'attestazione e la sua richiesta protetta bruciata.

Il deployer imposta anche la configurazione iniziale dell'account, della catena e della chiave di risposta e può modificare le impostazioni di gas del vault. Le richieste già avviate mantengono i valori di gas copiati quando sono iniziate.

Il test di produzione è il percorso di uscita completo

Il supporto per Mainnet rimane legato al ledger v9 nella roadmap di SIG. L'aggiornamento del repository del 21 ottobre prepara il pacchetto del vault 0.5.0 su SIG Midnight 0.25.0. A quella versione del codice, il registro degli indirizzi pubblicati contiene un indirizzo del vault stagenet e un'entrata mainnet vuota, che il file definisce come non ancora distribuita o pubblicata.

La demo full-stack separata di SIG utilizza Midnight stagenet ed Ethereum Sepolia, entrambi testnet pubblici, con un risponditore MPC "fakenet". Questo dimostra un flusso di applicazione. Non stabilisce che un quorum di produzione di firmatari indipendenti stia operando quella demo.

La descrizione della firma soglia di SIG affronta come viene prodotta una firma. Valutare un'effettiva distribuzione richiede anche sapere quanti firmatari devono cooperare, chi li gestisce, come tali disposizioni possono cambiare e quale recupero può completarsi quando il servizio ordinario non è disponibile.

L'ambito di audit necessita della stessa precisione. Il rapporto finale di Hacken datato 21 febbraio 2025 copre i contratti di firma della catena Ethereum Solidity. Il suo ambito non stabilisce la copertura del nuovo Compact vault o dell'intero sistema Nightmode.

Le prove di distribuzione successive sono quindi più significative di un altro annuncio di espansione: il codice di produzione esatto e gli indirizzi, la sua configurazione di firma e attestazione, la copertura di audit per quei componenti e un percorso di recupero abbinato al fallimento del servizio.

Questo contenuto è fornito a solo scopo informativo generale e non costituisce consulenza finanziaria, di investimento, legale o fiscale. Qualsiasi evento, ricompensa, promozione online o informazione correlata menzionata nel presente documento non deve essere considerata una raccomandazione, una sollecitazione o un invito ad acquistare, vendere, fare trading o altrimenti negoziare criptovalute. Le criptovalute sono altamente volatili e possono comportare perdite. La disponibilità dei servizi, dei prodotti e degli eventi correlati di WEEX può variare a seconda della regione. È tua responsabilità assicurarti che la tua partecipazione sia conforme alle leggi e ai regolamenti locali applicabili.