Dual Authoring — la soluzione di Loopring al Front-Running

Loopring è un protocollo utilizzato per creare exchanges decentralizzati. In questo post, esploreremo brevemente la questione del front-running negli exchanges decentralizzati, e vedremo come è stata risolta utilizzando la soluzione di Daniel, il Dual Authoring.

Una versione precedente è stata archiviata in IPFS: QmX48qyrSUdcvrJ2rFVrmvPxk6dkdoYKTGVBMRHC3ahzMh (PDF).

Daniel Wang, il nostro fondatore ha ricercato e sviluppato una soluzione migliore per la prevenzione del front-running chiamata, Dual Authoring. Abbiamo fatto richiesta per il brevetto e implementato la soluzione nei nostri smart contracts. Questa funzione sarà rilasciata nella versione 1.2 del nostro protocollo. Crediamo che il Dual Authoring ci porterà un vantaggio competitivo significativo.

Il Front-Running negli exchanges decentralizzati

“ Il termine Front running si riferisce alla pratica illegale per cui uno stockbroker esegue ordini di una security per il proprio tornaconto approfittando della conoscenza avanzata degli ordini pendenti dei suoi clienti.” [wikipedia]

Negli exchange decentralizzati, il front-running si verifica quando qualcuno tenta di minare transazioni, prima di minare le transazioni che si trovavano nell’insieme delle transazioni in corso(mempool). Questa azione può essere attuata specificando una commissione di transazione più alta (prezzo di gas), se il front-runner è un minatore, può ordinare transazioni pendenti a suo favore.

I principali schemi di front-running in Loopring (e in qualunque protocollo di abbinamento ordini) sono il furto di ordine (order-flich) e il furto di anello (ring-flich). Il furto d’ordine avviene quando un front-runner ruba uno o più ordini di un anello da una transazione pendente; il furto di anelli avviene quando un front-runner ruba l’intero anello della transazione pendente.

Prima di continuare, vale la pena menzionare che il sistema di abbinamento di Loopring non garantisce di essere serviti per ordine di arrivo (invece, usa il modello over-the-counter o modello OTC), ciò significa che le marche temporali (timestamps) degli ordini vengono totalmente ignorate. Questo implica che uno scambio front-running non ha impatto nel prezzo reale di quello scambio –Loopring supporta soltanto ordini a prezzo limitato.

Anatomia degli ordini e anelli nelle versioni di Loopring 1.0 & 1.1

Ordini e firme

Gli ordini in Loopring sono creati da wallet e strumenti che possono aiutare ad organizzare le chiavi private degli utenti. Gli ordini sono JSON snippets e sono trasferiti ai relè sotto forma di pacchetti dati JSON attraverso APIs. Qui di seguito un esempio di un ordine nella versione 1.0 di Loopring:

Un ordine in Loopring 1.0

Dove, il campo ownerrappresenta l’owner_address dell’ordine cui i tokens saranno trasferiti una volta che questo sarà concluso. L’ordine (incluso lo owner_address) deve essere firmato con la chiave privata del owner_address’ L’ordine è valido solo se la order_signature (rappresentata dar, v, eds) è valida.

Come illustrato nel diagramma in basso, la order_signature è firmata contro l’hash dell’ordine (o order_hash), il quale è in realtà l’output della funzione keccak256 di tutti gli altri campi eccettor, v, eds.

Un ordine in Loopring 1.0 e 1.1

È facile calcolare l'order_hash il quale viene usato per verificare se l’indirizzo firmatario è infatti l’ owner_address dell’ordine o no. I relè verificheranno la firma di ogni ordine che ricevono; lo smart contract del protocollo di Loopring verifica anche le firme degli ordini quando 1) gli ordini sono inviati come parte di un anello e 2) gli ordini sono inviati per essere cancellati.

Anelli e firme

Gli anelli non prendono una forma JSON, invece sono rappresentati da tutti i parametri della funzione submitRing fornita dal protocollo di Loopring. Ma se visualizziamo un anello, somiglierà in qualche modo all’’immagine sottostante — incapsulando tutti i dati dei suoi ordini (un anello può avere da 2 a 10 ordini). Il minatore dell’anello vorrà anche inserire il suo indirizzo (il miner_address) e altri parametri di estrazione (o parametri di anello) (mining parameters or ring parameters) nell’anello così che la funzione submitRing si comporterà diversamente in base agli input di questi parametri.

I minatori hanno bisogno di firmare un hash ring ( ring_hash), insieme a tutti i parametri di estrazione (mining parameters) con la chiave privata del miner_address. Ilring_hash può essere calcolato come il risultato XOR di tutti gli order_hashs o usando altre funzioni dell’hash.

Processo di firma di un anello in Loopring (1.0)

È importante notare che il protocollo non richiede a msg.senderdi firmare nulla. In altre parole, un anello –come le transazioni in submitRing– può essere firmato da un indirizzo di estrazione (mining address) e la transazione della blockchain stessa può essere firmata (e trasmessa) da un diverso indirizzo di transazione. La separazione degli indirizzi di estrazione e indirizzi di transazione fornisce ulteriore flessibilità e vantaggi sulla sicurezza.

Il diagramma che segue, illustra il pacchetto dati (o i parametri) di una transazione submitRing per un anello di 3 ordini.

Pacchetto dati della Funzione submitRing (3 Ordini)

Perché i minatori hanno bisogno di firmare gli anelli? Abbiamo bisogno di accertarci che ogni statistica di scambio venga calcolata/aggiornata per i minatori giusti. Queste statistiche potrebbero essere usate da membri della Blockchain del consorzio di condivisione di liquidità per calcolare ogni produzione e consumo dell’ordine del membro, per consolidare i pagamenti tra consorziati.

Front-Running e anelli rubati

Come descritto nella sezione precedente quando una transazione submitRing non è stata confermata e si trova ancora nell’insieme delle transazioni in corso, chiunque può facilmente trovare queste transazioni e rimpiazzare il miner_address con il proprio indirizzo (ilfilcher_address) , a questo punto può ri-firmare il pacchetto dati con ilfilcher_address per sostituire la firma dell’anello. Il fincher può specificare un prezzo di gas più alto e inviare una nuova transazione sperando che i minatori di blocchi prendano la sua nuova transazione nel prossimo blocco invece della transazione originale submitRing .

Pacchetto dati Rubato (3 Ordini)

La soluzione in 1.0 e in 1.1

In v1.0 e 1.1 permettiamo ai minatori di anelli di richiamare le funzioni batchSubmitRinghash o submitRinghash per riservare gli hash degli ordini prima di inviare l’anello reale. Quando un anello è inviato, il protocollo controlla se l’hash dell’anello è stato già inviato/riservato da altri minatori, se è così il protocollo rigetterà l’anello e la transazione submitRing fallirà.

Ci sono anche dei lati negativi in questa soluzione: richiede più transazioni quindi il costo di gas per i minatori è più alto; e richiede almeno il doppio del tempo (in block time) per risolvere un anello. Questo è inaccettabile.

Dual Authoring — La nostra nuova soluzione

La nostra nuova soluzione prevede il meccanismo di installazione di due livelli di autorizzazione per gli ordini: uno per il pagamento/insediamento, e uno per l’estrazione. Lo abbiamo chiamato Dual Authoring.

Come funziona

Ecco come funziona il Dual Authoring:

1. Per ogni ordine, il wallet genererà una coppia di chiave pubblica/chiave privata casuale, la coppia di chiavi verrà inserita nel JSON snippet dell’ordine. (Un’alternativa è quella di usare l’indirizzo derivato dalla chiave pubblica invece che la chiave pubblica di per sé per ridurre la dimensione in termini di byte. Utilizziamo auth_address per rappresentare questo indirizzo, eauth_private_key per raffigurare la corrispondente chiave privata auth_addres).
2. 2. Tutti i campi nell’ordine eccetto auth_private_key vengono firmati usando la chiave privata delowner_address(nonauth_private_key) come mostrato nell’immagine seguente.

Un Ordine in Loopring 1.2

3. Il wallet manderà l’ordine insieme al auth_private_key ai minatori (relè) per essere abbinato. I minatori verificheranno che auth_private_key e auth_address siano abbinate correttamente e che la firma dell’ordine sia valida rispetto all’indirizzo del owner_address.

4. Quando un anello è stato identificato, i minatori useranno ogniauth_private_key dell’ordine per firmare il ring_hash, miner_address, e tutti i parametri di estrazione. Nell’esempio sottostante, l’anello contiene 3 ordini, quindi vi saranno 3 firme dalle 3 auth_private_keys. Chiamiamo queste firme le auth_signatures. I minatori avranno anche bisogno di firmare il ring_hash insieme con tutti i parametri di estrazione usando la chiave privata delminer_address allo stesso modo del protocollo v1.0 e 1.1.

Processo di firma di un Anello in Loopring (1.2) utilizzado Dual Authoring

5. Il minatore richiama la funzione submitRing con tutti i parametri già esistenti in v1.0 e 1.1, e allo stesso tempo le 3 auth_signatures. extra. È importante notare che auth_private_keys NON sono parte delle transazioni on-chain e quindi rimangono sconosciute ad altre parti ad eccezione del relè, come mostrato nell’immagine che segue.

Un Anello in Loopring (1.2) (visibile solamente come transazione on-chain)

6. Il protocollo di Loopring verificherà ognuna delle auth_signature rispetto al corrispondente auth_address di ogni ordine, e rifiuterà l’anello se qualcuna delle auth_signature è invalida.

Perchè funziona

In questo modo nessun anello può essere rubato a meno a che non abbia tutte leauth_private_keys degli ordini allegati. Questo perché:

• La firma dell’ordine (attraverso la chiave privata dell’ ower_address) garantisce che gli ordini non possano essere modificati, incluso il auth_address.
• La firma del minatore (attraverso la chiave privata del miner_address) garantisce che nessuno possa usare la sua identità per minare un anello..
• Le auth_signatures garantiscono che l’intero anello non possa essere modificato, incluso il miner_address. Inoltre, visto che i ring-flichers non hanno accesso alle auth_private_keys, non possono rigenerare un nuovo set di of auth_signatures, quindi non potranno generare una transazione flich.

Varianti del Dual Authoring

Dual Authoring Parziale

Il Dual Authoring richiede firme per ogniauth_private_key n un anello. Una variante del Dual Authoring è quella di richiedere una o solo alcune auth_signatures. Anche questo schema di Dual Authoring parziale garantisce che un anello non possa essere rubato nella sua interezza, ma è ancora soggetto a furto di ordini (order-flich), e il flicher può usare gli ordini rubati in un’altra Dual Authoring parziale, attivando pagamenti di transazioni in anelli dove le auth_private_keys egli ordini rubati non sono richieste.

Key-Sharing Dual Authoring

Un relè potrebbe generare una coppiaauth_address /auth_private_key e richiedere a tutti i wallet connessi ad essa di usare lo stessoauth_address condiviso, per tutti gli ordini (dato che i wallet non hanno la auth_private_key, this field is missing from order’s JSON API payload). key, questo campo è mancante nei pacchetti dati di ordini JSON API). Questo schema Key-Sharing Dual Authoring, autorizza solo i relè a minare gli ordini che sono generati dalle coppie auth_address/auth_private_key. Quindi i wallet non hanno l’opzione di condividere ordini con altri relè.

Implementazione

La Dual Authoring è stata implementata nella repository del nostro protocollo, la pull request i è attualmente in fase di revisione, i test saranno aggiornati a breve.

Riepilogo

La soluzione di Daniel, il Dual Authoring , previene furti di anello (ring flich) e furti di ordini (order-flich) nel contempo assicura che il regolamento dell’anello possa essere fatto in una sola transazione. In aggiunta, la Dual Authoring apre le porte ai relè per la trasmissione di ordini condivisi in due modi: condivisioni che non combaciano e condivisioni che combaciano.

Se hai domande o suggerimenti in merito alla Dual Authoring, contatta direttamente Daniel a questo indirizzo email.

Aggiornamento: Abbiamo deciso di rilasciare questa feature come parte della versione v1.1.

Per ricevere più informazioni e restare sempre aggiornato, seguici su:
⭑ Twitter: twitter.com/loopring.org
⭑ Telegram: t.me/loopring_en
⭑ Telegram: t.me/loopring_it(Italiano)
⭑ Reddit: reddit.com/r/loopringorg
⭑ Email: foundation@loopring.org (most responsive)