CEX, DEX e custodia

Master sorgente EN · P01-L06 · 30 minuti stimati · needs_review

Studio in sola lettura. Nessuna connessione del wallet, fondi reali, frase seed, chiave privata, firma o operazione in tempo reale. La durata è una stima editoriale; i visual sono specifiche, non componenti distribuiti.

«Exchange» indica una categoria di servizi, non un unico modello di fiducia. Saldo di conto, saldo di wallet e posizione in un pool possono esporre un utente ad attori e regole differenti.

Separare custodia ed esecuzione

La custodia chiede chi può autorizzare il movimento e a quali condizioni. L'esecuzione chiede come uno scambio proposto venga abbinato o prezzato e regolato. Una sede centralizzata può conservare un saldo interno per un cliente controllando l'infrastruttura di firma sottostante. Quel modello è stipulato nel caso CEX di questa lezione; non va esteso a ogni prodotto senza verificarne termini e progettazione.

Un DEX può eseguire tramite contratti e pool di liquidità; la panoramica di Uniswap descrive quel meccanismo [UNI]. Un'interfaccia web non è l'intero protocollo. Al contrario, un percorso tramite contratti non elimina ogni dipendenza. Comportamento del codice, autorizzazioni, instradamento, interfacce e fonti dei dati restano rilevanti.

Seguire il percorso di asset e autorizzazioni

Per ogni fase chiedere: dove è registrato il saldo, che cosa autorizza il movimento, chi può fermare l'elaborazione e quale evidenza dimostra il completamento? Un'esecuzione interna della sede potrebbe non creare una transazione separata sulla blockchain pubblica per quel cliente. Un record di prelievo risponde a una domanda diversa da un record di scambio interno.

Per un'interazione con contratto mediata dal wallet, distinguere l'autorità del conto dallo spender o dal contratto che autorizza. Le regole dei conti Ethereum spiegano l'esistenza di conti controllati da chiavi e codice [ACCT]; non autenticano uno specifico exchange né dimostrano quante persone lo controllino.

Confrontare i guasti, non gli slogan

Nel CEX fittizio, una pausa dei prelievi può bloccare l'elaborazione verso l'esterno anche mentre i record interni restano visibili. Nel DEX fittizio, un'interfaccia indisponibile può bloccare il flusso di quella interfaccia senza dimostrare che i contratti sottostanti si siano fermati. Nessuno dei casi giustifica provare un altro sito o inviare fondi in questo esercizio. Registrare invece le evidenze tecniche o di servizio mancanti.

Costruire un confronto circoscritto

Usare una matrice anziché un'unica etichetta di sicurezza. Includere autorizzazione, metodo di esecuzione, evidenza del completamento e dipendenze residue. Un rapporto di audit, se fornito, avrebbe una versione e una portata; l'assenza di un problema visibile non prova solvibilità o correttezza. Il confronto serve a comprendere le assunzioni, non a raccomandare una piattaforma.

Classificazione degli stati dell'evidenza

OBSERVED nei dati dell'esercizio: assegnazioni di custodia/esecuzione, pausa dei prelievi e indisponibilità dell'interfaccia. INFERRED: confronto delle dipendenze secondo i modelli dichiarati. UNKNOWN: solvibilità effettiva, perdite e stato dei contratti. INSUFFICIENT EVIDENCE: una delle interruzioni operative dimostra una perdita o uno dei modelli garantisce sicurezza universale.

• CEX: exchange centralizzato, gestito da un fornitore di servizi.
• DEX: exchange decentralizzato, con esecuzione governata da regole di protocollo come gli smart contract.
• Custodia: autorità sul movimento degli asset.
• Registro interno: record dei clienti mantenuti dal servizio.
• Pool: disponibilità per gli scambi detenuta dal contratto.
• Evidenza del regolamento: record che sostengono il completamento del movimento.

ILLUSTRATIVE. VENUE-C conserva i saldi internamente e autorizza da solo i prelievi; abbina gli ordini internamente. ROUTE-D usa contratti autorizzati dall'utente e un pool contenente TOKEN-A/TOKEN-B; la sua interfaccia è gestita da WEB-D. A T1 VENUE-C riporta prelievi sospesi; WEB-D è indisponibile. Non sono forniti record di solvibilità o stato dei contratti.

Confronto di custodia ed esecuzione: registro interno C e confine separato dei prelievi; pool D TOKEN-A/TOKEN-B e confine separato dell'interfaccia WEB-D. Testo alternativo: abbinamento interno ed esecuzione nel pool hanno autorità ed evidenze distinte.

Le distinzioni fittizie di custodia/esecuzione e le condizioni di disponibilità riportate.

Solvibilità, recuperabilità, assenza di vulnerabilità o raccomandazione di una piattaforma.

• Chiamare ogni guasto d'interfaccia un guasto della blockchain.
• Equiparare un saldo interno visibile a una ricevuta pubblica.
• Dichiarare l'esecuzione senza custodia priva di rischi.

Creare il confronto a quattro colonne. Una delle osservazioni T1 dimostra asset persi? Quale evidenza successiva risponderebbe a elaborazione, solvibilità e disponibilità dei contratti come questioni distinte?

Consegnare una breve tabella dell'evidenza e una motivazione basate soltanto sul materiale fornito. Ripartizione suggerita: studio 12 min, verifica/calcolo 8 min, correzione/quiz 10 min.

• Identificare l'autorità sul movimento.
• Identificare dove avviene l'esecuzione.
• Indicare l'evidenza del completamento.
• Separare disponibilità e solvibilità.

«Exchange» indica una categoria di servizi, non un unico modello di fiducia. Saldo di conto, saldo di wallet e posizione in un pool possono esporre un utente ad attori e regole differenti. Il materiale fornito sostiene le distinzioni fittizie di custodia/esecuzione e le condizioni di disponibilità riportate. Non dimostra solvibilità, recuperabilità, assenza di vulnerabilità o raccomandazione di una piattaforma.

• Confrontare chi autorizza i trasferimenti e chi esegue gli scambi.
• Separare accesso all'interfaccia dell'exchange e custodia.
• Registrare le dipendenze residue senza classifiche universali.

P01-L07 dopo aver verificato esercizio e prerequisiti.

NONE. Il catalogo autorevole non richiede accesso al prodotto per questa lezione. Usare materiale congelato senza connessione di rete.

• [UNI] Panoramica del protocollo Uniswap — Scambio tramite pool e smart contract; solo meccanismo. Verificata 2026-10-01.
• [ACCT] Conti Ethereum — Conti e autorità di firma, distinti dalle interfacce dei wallet e dall'identità umana. Verificata 2026-10-01.

I valori sintetici sono dati didattici creati dall'autore. Dove applicabile, i valori storici devono usare il dataset collegato e la sua provenienza più circoscritta. La verifica delle fonti non è un'approvazione editoriale indipendente.