Un mese dopo il rilascio del bridge sulla mainnet, Cheng, Hongchao e Maud sono stati intervistati da Vladimir in uno spazio Twitter AMA. Puoi ascoltare lo spazio Twitter stesso qui, o continuare a leggere al tuo ritmo! Questo articolo è una versione leggermente modificata dell’AMA, per migliorarne la chiarezza e la leggibilità. Questa è la parte 2 di 3 e puoi trovare la parte 1 qui e la parte 3 qui
La tabella di marcia
Dopo aver raggiunto traguardi significativi, c’è sempre un periodo di adattamento mentre passiamo alla fase successiva. Poiché il nostro team è composto da costruttori che danno priorità allo sviluppo, abbiamo sempre un elenco di cose che vogliamo costruire a breve e lungo termine. Spesso lavoriamo su più progetti contemporaneamente. Con il lancio del portafoglio mobile e del bridge, la nostra attenzione si sta rivolgendo alle ottimizzazioni future e ai nuovi sviluppi, con la prossima grande impresa che sarà un aggiornamento della rete.
Vladimir: Cheng ha accennato al prossimo aggiornamento della rete su Discord. Potresti condividere maggiori dettagli su questo aggiornamento? Nello specifico, quali sono i punti focali dell’imminente aggiornamento e quali sono i tempi previsti per la sua implementazione?
Cheng: Il primo aggiornamento della rete, Leman, è stato enorme. Ha migliorato Alephium in modo significativo, abilitando le attuali dApp. Questo aggiornamento è stato progettato insieme allo sviluppo del ponte e del DEX. Le caratteristiche principali includevano il sistema di subappalto dApp, il sistema APS e un nuovo algoritmo di regolazione della difficoltà per stabilizzare le variazioni di difficoltà su diversi canali. Dato che si trattava del primo aggiornamento di rete per un nuovo livello uno con una nuova macchina virtuale e un nuovo linguaggio di programmazione, ci si aspettava un certo perfezionamento dopo il lancio.
Da allora, la fondazione si è dimostrata solida, come dimostra il successo nello sviluppo di prodotti come il DEX, l’Alephium Bridge e il Deadrare NFT Marketplace. Abbiamo anche ricevuto preziosi feedback dalla community e dagli sviluppatori. Il prossimo aggiornamento si concentrerà sul miglioramento della blockchain sulla base di questo feedback, mirando in particolare alle esperienze degli utenti e degli sviluppatori. Questa attenzione mira a rispondere al feedback comune e si prevede che aumenterà significativamente l’adozione.
Vladimir: Puoi dirci di più sulla riduzione del tempo di blocco? Ne hai parlato un paio di volte su Discord. Perché avete deciso che era una delle priorità? Ridurre il tempo di blocco è sicuro?
Cheng: La riduzione del tempo di blocco è un argomento molto dibattuto nello spazio proof of work e non c’è consenso sul tempo di blocco ideale per le blockchain proof of work. Tempi di blocco più lunghi significano una catena più leggera per quanto riguarda lo storage e il calcolo della CPU, poiché il tasso di blocchi uncle/orphan è inferiore. Tuttavia, i tempi di blocco più brevi sono più facili da usare, soprattutto per gli utenti non tecnici, in quanto non devono chiedersi perché le transazioni impiegano così tanto tempo per essere incluse nella blockchain. Tempi di blocco più brevi hanno anche vantaggi tecnici, come una mempool più piccola in casi normali, semplificando lo sviluppo sia sul lato full node che nelle applicazioni che interagiscono con la mempool.
La sfida sta nel trovare un equilibrio che consenta alla blockchain di funzionare in modo efficiente, anche su larga scala, in modo simile a reti come Bitcoin o Ethereum. Una delle principali preoccupazioni è il tempo di propagazione dei blocchi nelle reti di grandi dimensioni; Un tempo di blocco troppo breve potrebbe aumentare il numero di blocchi orfani/UNCLE, compromettendo la sicurezza della rete. Attualmente, i parametri selezionati da Ethereum rappresentano una scelta solida. Abbiamo in programma di adottare un approccio simile per il nostro prossimo aggiornamento, ma potrebbe esserci spazio per ridurre ulteriormente il tempo di blocco a lungo termine.
Voglio sottolineare che la riduzione del tempo di blocco può avere implicazioni per la sicurezza. Ad esempio, ridurlo a 10-20 secondi potrebbe comportare un tasso di orfanità di circa il 15%, il che significa una potenziale compromissione del 15% della sicurezza. Tuttavia, esistono metodi per mitigare questo problema, come l’algoritmo Ghost. Questo algoritmo incorpora gli hash dei blocchi orfani in nuovi blocchi, assicurando che gli sforzi nella creazione di questi blocchi orfani non vengano sprecati e facciano ancora parte della blockchain principale. Il compromesso in questo caso comporta maggiori requisiti di archiviazione, poiché più dati verranno archiviati su disco.
Questo compromesso è accettabile per Alephium, che è progettato come una blockchain frammentata, leggera ed efficiente. Un tempo di blocco di 16 secondi è fattibile per Alephium in questo momento. Potrebbe esserci il potenziale per ridurre ulteriormente il tempo di blocco poiché la larghezza di banda e le capacità della CPU continuano ad evolversi ogni anno. Ciò significa che la propagazione e la convalida dei blocchi diventano più veloci ogni anno. Quindi significa che il tasso di orfani non è un problema.
Vladimir: Quindi stai dicendo che il nostro obiettivo attuale è quello di ridurre il tempo di blocco da 64 a 16 secondi. In questo modo, miriamo a mantenere lo stesso livello di sicurezza aumentando significativamente la velocità delle transazioni. L’unico compromesso per questo miglioramento sarebbe un leggero aumento dei requisiti di archiviazione.
Cheng: Esattamente, questo è il modo per riassumere.
Vladimir: L’aumento di quattro volte del numero di blocchi nello stesso lasso di tempo significa che ogni blocco riceverà solo un quarto della ricompensa precedente? E quali sono i potenziali compromessi, soprattutto per quanto riguarda l’impatto sulla velocità delle emissioni dei token?
Cheng: Abbiamo in programma di adeguare le emissioni simboliche per garantire che le emissioni totali rimangano costanti. Ciò significa che il protocollo emetterà complessivamente la stessa quantità di token.
Quando riduciamo il tempo di blocco da 64 a 16 secondi, la ricompensa del blocco verrà ridotta di un fattore quattro. Tuttavia, questo adeguamento da solo è insufficiente a causa della presenza di blocchi orfani nella blockchain, simili alla versione proof-of-work di Ethereum. Di conseguenza, premieremo anche i miner per questi blocchi orfani. Questo ci impone di destinare una parte della ricompensa della catena principale a questi blocchi orfani. Per farlo in modo efficace, dobbiamo prima stimare il tasso di orfani. Abbiamo in programma di utilizzare i dati della catena proof-of-work di Ethereum come riferimento, apportando le modifiche necessarie per adattarli al nostro contesto.
Vladimir: Nel quadro generale, non cambia nulla per quanto riguarda il programma di emissione dei token. Non cambia molto anche per i miner, giusto?
Cheng: La modifica del tempo di blocco non cambierà l’emissione complessiva.
Vladimir: Puoi spiegare cosa significa astrazione di gruppo e perché è importante? E questo significa che non dovrò mai più considerare su quale gruppo creare un indirizzo? Come funziona l’astrazione di gruppo con le dApp?
Hongchao: La necessità di un’astrazione di gruppo deriva dal nostro design partizionato, che, pur migliorando la scalabilità, può introdurre alcuni inconvenienti. Ad esempio, con indirizzi esistenti in gruppi diversi, le applicazioni distribuite in un gruppo sono accessibili solo dagli indirizzi all’interno di quel gruppo specifico. È importante notare che questa limitazione non si applica ai trasferimenti di token. È possibile trasferire liberamente i token da un indirizzo di un gruppo a un indirizzo di qualsiasi altro gruppo senza problemi. Pertanto, quando si parla di astrazione di gruppo, si riferisce in modo specifico a scenari in cui gli indirizzi e le applicazioni si trovano in gruppi diversi, potenzialmente in più gruppi.
In che modo il portafoglio e le dApp interagiscono per offrire agli utenti un’esperienza fluida? Ad esempio, il marketplace NFT è attualmente distribuito nel gruppo zero, richiedendo agli utenti di avere un indirizzo in questo gruppo. Se un utente ha un indirizzo nel gruppo due e vuole acquistare un NFT, il processo non è semplice al momento. Prima di effettuare l’acquisto, dovrebbero creare un indirizzo nel gruppo zero e trasferire manualmente i token dal loro indirizzo del gruppo due a questo nuovo indirizzo.
Questa non è un’esperienza ottimale. Tuttavia, c’è la possibilità che il portafoglio automatizzi questo processo, gestendo questi trasferimenti e interazioni in modo più efficiente. Ad esempio, se un utente desidera acquistare qualcosa dal marketplace NFT distribuito nel gruppo zero, ma il suo indirizzo è nel gruppo due, il portafoglio potrebbe creare automaticamente un indirizzo nel gruppo zero per lui. Potrebbe quindi trasferire i token necessari a questo nuovo indirizzo, completare l’acquisto e trasferire nuovamente l’articolo acquistato all’indirizzo del gruppo due dell’utente. Questo processo eliminerebbe la necessità di trasferimenti manuali e di gestione degli indirizzi da parte dell’utente.
Questo scenario è solo un esempio di come possiamo astrarre il concetto di gruppi per migliorare il percorso dell’utente. L’efficacia di questa astrazione dipende in gran parte da come è scritta la dApp. Ottenere un’esperienza senza soluzione di continuità richiede uno sforzo coordinato tra la dApp e il portafoglio, che è un aspetto chiave di ciò che considero astrazione di gruppo nella funzionalità del portafoglio.
Vladimir: Quindi l’obiettivo è che le persone non si preoccupino dei gruppi quando usano il portafoglio.
Hongchao: Non so se si possa rimuoverlo completamente, l’obiettivo è quello di ridurlo al minimo in modo significativo. L’obiettivo è garantire che non diventi una delle principali preoccupazioni per l’esperienza utente (UX), poiché attualmente è una delle principali lamentele degli utenti.
Vladimir: Maud vuole aggiungere qualcosa.
Maud: In effetti, come accennato in precedenza, ci sono vari metodi per migliorare l’esperienza dell’utente, tra cui miglioramenti del portafoglio e sviluppi del backend. Le modifiche a livello di blockchain o endpoint potrebbero anche facilitare interazioni più fluide. È importante riconoscere che, nonostante le sfide esistenti, la nostra esperienza di partizionamento orizzontale rimane relativamente fluida. Il nostro design basato su UTXO ci consente di implementare un design di partizionamento orizzontale più facile da usare. Anche se non è impeccabile, è incoraggiante sapere che il perfezionamento di questo aspetto sarà un obiettivo primario in futuro.
Vladimir: Il processo di costruzione e ottimizzazione, con la sua continua dinamica avanti e indietro, è davvero affascinante. Questo mi porta a una domanda per Chang in merito ad altri elementi interessanti della roadmap, come il supporto alle transazioni senza gas e lo sviluppo di ulteriori proof of concept. Questi proof of concept per le dApp sono cruciali in quanto forniscono progetti fondamentali su cui i team possono costruire, come dimostra il loro ruolo strumentale nello sviluppo del DEX e del mercato NFT.
Cheng, potresti spiegare brevemente cosa significa supporto per le transazioni senza gas? Inoltre, potresti condividere approfondimenti sulle prossime dApp e se ci sono piani per espandere il supporto del portafoglio hardware? Lei può affrontare la prima parte, e io posso continuare con le altre domande in seguito.
Cheng: Rispondendo alla prima domanda, le transazioni senza gas riguardano principalmente l’esperienza dell’utente. Ad esempio, quando un nuovo utente effettua il bridge di token da Ethereum ad Alephium, utilizza $ETH per pagare la transazione che invia i token al bridge. Da parte di Alephium, avranno bisogno di $ALPH per interagire con la blockchain e richiedere i loro token dal bridge. Questo requisito è scomodo per gli utenti che non hanno accesso immediato ai $ALPH, poiché in genere devono acquistarli in anticipo da exchange centralizzati, il che può essere problematico.
Le transazioni senza gas mirano ad assistere gli utenti in situazioni in cui dispongono di token ma non hanno l’ALPH per pagare il gas necessario per le transazioni. Nell’ecosistema Ethereum, ci sono proposte per affrontare questo problema, la maggior parte delle quali prevede l’utilizzo di relay off-chain per coprire le commissioni del gas per conto degli utenti. Questo approccio è progettato per semplificare il processo per i nuovi utenti che non dispongono dei token necessari per pagare le commissioni del gas.
La sfida di questa implementazione è la necessità di un componente off-chain, che comporta un lavoro considerevole. Al momento è disponibile un inoltro per il bridge e la gestione di questo comporta una notevole quantità di codice e la necessità di risolvere i problemi di sicurezza. Tuttavia, prevediamo di introdurre nuove istruzioni nella macchina virtuale nel prossimo aggiornamento. Queste istruzioni consentiranno a ogni progetto di creare un contratto senza gas, consentendo agli utenti di avere la copertura delle tariffe del gas per servizi specifici.
Questo approccio sarà completamente on-chain, eliminando la necessità di componenti off-chain, rendendolo così completamente decentralizzato e più sicuro. Semplifica il processo, poiché i progetti devono solo scrivere un semplice smart contract utilizzando il nostro framework. Questo lo rende non solo sicuro, ma anche comodo da implementare. Ciò potrebbe portare alla creazione di vari progetti e nuovi servizi sulla nostra piattaforma, il che è una prospettiva entusiasmante.
Vladimir: Questo è davvero uno sviluppo entusiasmante. Faciliterà in modo significativo l’accesso ad Alephium sia per gli utenti che per gli sviluppatori, il che è un’ottima notizia. Andando avanti, un altro aspetto da considerare è l’esperienza del portafoglio. Ciò include un supporto migliorato per la funzionalità multi-firma nell’SDK e un maggiore supporto per i portafogli hardware. Potresti approfondire questi miglioramenti?
Cheng: Sì, il supporto per l’hardware wallet è sempre stato un obiettivo per noi, ma le limitazioni della larghezza di banda ne hanno ritardato l’implementazione. A seguito dell’aggiornamento della rete, prevediamo di dare priorità a questo sviluppo. Il codice è open-source, consentendo agli utenti di inviare transazioni in modalità “cieca”. Ciò significa che con l’installazione manuale dell’app Ledger, gli utenti possono già utilizzare l’hardware Ledger per inviare transazioni in base all’hash della transazione. Si tratta di un significativo passo avanti e puntiamo a svilupparlo dopo l’aggiornamento della rete.
L’aspetto principale che dobbiamo ancora implementare è la funzionalità di decodifica. Ciò comporta che il portafoglio hardware riceva e decodifichi la transazione, calcola l’hash della transazione dai dati grezzi e visualizza i dettagli della transazione all’utente. L’implementazione di questo migliorerà la sicurezza, anche se anche il nostro attuale processo di transazione “cieco” segna un miglioramento significativo della sicurezza.
Abbiamo in programma di concentrarci presto sullo sviluppo di questa funzione di decodifica. Date le solide basi che abbiamo già stabilito, non dovrebbe volerci troppo tempo per completarlo. L’unico vincolo è stato il nostro tempo, ma ci impegniamo ad affrontarlo come priorità.
Vladimir: L’ultima domanda su questo argomento riguarda i proof of concept delle dApp. Quali ti interessano di più?
Cheng: Trovo particolarmente intriganti i protocolli di prestito e le stablecoin. Il mio interesse personale risiede nell’esplorare due concetti. Il primo sono i protocolli Oracle-free, generalmente più sicuri di quelli basati su Oracle e meno vulnerabili agli attacchi di manipolazione dei prezzi. Tali attacchi hanno spesso preso di mira i protocolli su EVM, colpendo anche importanti progetti DeFi. Attualmente, i protocolli senza Oracle stanno guadagnando terreno in questo settore. Su EVM, l’adattamento ai nuovi protocolli è più impegnativo a causa della forte integrazione dei protocolli basati su Oracle esistenti in vari sistemi, che li rende difficili da sostituire. La nostra blockchain è relativamente nuova, quindi rappresenta un’ottima opportunità per sperimentare e adottare questi protocolli.
Un’altra applicazione che non vedo l’ora di vedere evolversi è il trading basato sull’intento. Molti exchange decentralizzati (DEX) attualmente operano sul modello di market-making automatizzato (AMM), che funziona bene con una liquidità sostanziale. Tuttavia, nei casi in cui la liquidità non è così elevata, un modello di order book potrebbe essere più efficiente. Per affrontare questo problema, c’è un interesse emergente per il modello di trading basato sull’intento. La versione di Uniswap si muove in questa direzione, insieme ad altri progetti che esplorano concetti simili.
Dato che si tratta di progetti in fase relativamente iniziale, possiamo adottare e adattare questi nuovi tipi di protocollo. Il nostro utilizzo del modello UTXO si allinea bene con lo stile dell’order book delle dApp, offrendo un vantaggio significativo per l’implementazione di protocolli di trading intent-based e la facilitazione delle transazioni peer-to-peer. A differenza del modello di Ethereum, che in genere consente un solo mittente per transazione, la nostra piattaforma è in grado di gestire più mittenti, aprendo una serie di nuovi casi d’uso. Sono particolarmente entusiasta di vedere esperimenti e sviluppi in questo settore, in quanto promettono di portare funzionalità innovative e diversificate alla nostra piattaforma.
Questa è la fine della parte 2 della trascrizione dell’AMA! La Parte 3 arriverà la prossima settimana!
