🇮🇹 "Implementazione di progetti di aste utilizzando Hydra"

[lordwotton]

Traduzione italiana di “Implementing auction projects using Hydra - IOHK Blog”

Traduzione italiana a cura di Lordwotton di RIOT Stake Pools. Se apprezzi queste traduzioni, per favore valuta di supportare il mio lavoro delegando i tuoi ada a RIOT entra nel nostro gruppo Telegram

---

Implementazione di progetti di aste utilizzando Hydra

Un documento di IOG e MLabs che presenta un modo per gestire le aste utilizzando Hydra

Questo progetto è una collaborazione tra Input Output Global, Inc. (IOG) e MLabs Ltd. (MLabs) per sviluppare un’implementazione di riferimento per un’asta che utilizza i protocolli Hydra. Lo scopo è duplice:

1. Dimostrare che è possibile sviluppare applicazioni sostanziali per un caso d’uso importante con l’attuale implementazione di Hydra.
2. Determinare e allineare in modo costruttivo il design del protocollo Hydra Head con i casi d’uso concreti esistenti nell’ecosistema Cardano e semplificare l’adozione del protocollo da parte degli sviluppatori.

La speranza è che questo progetto, e altri progetti simili incentrati su altri casi d’uso, aprano la strada alla comunità di Cardano per iniziare a utilizzare Hydra per la scalabilità nella pratica comune.

Protocollo Hydra Head

Hydra è una famiglia di protocolli destinati a fornire la soluzione di scalabilità di livello 2 (L2) per Cardano. Il protocollo Hydra Head è il primo protocollo di questa famiglia: si tratta di una suite di smart contract e software che consente a qualsiasi gruppo di partecipanti di stabilire canali di stato isomorfi e multi-party (Hydra Heads) tra loro. Il protocollo Hydra Head sarà utilizzato in questo progetto.

Le Hydra Heads consentono ai partecipanti di effettuare transazioni tra loro, utilizzando i fondi che hanno trasferito nei canali di stato, senza doverli inviare alla rete principale di Cardano (L1). Il risultato finale di queste interazioni tra i partecipanti a Hydra Head può essere riportato a Cardano L1 chiudendo l’Hydra Head, che libera i fondi al suo interno per essere utilizzati in altri Hydra Head o in altro modo su Cardano L1.

Le transazioni all’interno di una Hydra Head hanno lo stesso formato e le stesse proprietà delle transazioni su Cardano L1 - sono isomorfe. In linea di principio, ciò consente alle DApp Cardano di riutilizzare una porzione significativa della loro base di codice quando passano alcuni dei loro smart contract all’uso di Hydra.

Un’eccezione a questa proprietà di isomorfismo è che la coniatura/bruciatura di token all’interno di una Hydra Head non può influenzare Cardano L1. L’unica cosa che una Hydra Head può fare su Cardano L1 è la ridistribuzione dei token esistenti dagli UTXO impegnati nella Hydra Head a nuovi UTXO. Questo avviene in base alle transazioni a cui i partecipanti hanno acconsentito all’interno dell’Hydra Head.

Ci sono anche alcune differenze tra i protocolli di consenso di Cardano L1 e Hydra L2. Ciò potrebbe richiedere alle DApp Cardano esistenti di adattare il loro design in modo da poter mantenere il comportamento desiderato all’interno dell’ambiente Hydra Head. In particolare, a differenza di Cardano L1, i partecipanti a Hydra Head devono tutti rimanere online e rispondere l’uno all’altro, durante il funzionamento di Hydra Head, e tutti i partecipanti devono riconoscere e accettare ogni transazione all’interno di Hydra Head perché questa abbia effetto.

Le applicazioni possono essere eseguite all’interno di una singola testa, oppure possono essere distribuite su una rete di teste Hydra. Quando un’applicazione è distribuita su una rete di Hydra Heads, il suo stato globale può essere evoluto sia attraverso la comunicazione tra Hydra Heads (bypassando L1) sia sincronizzando gli stati delle teste locali con L1 e risolvendoli lì.

Esiste un catalogo in evoluzione di topologie di rete di teste Hydra, ognuna con i suoi vantaggi/limitazioni. Si prevede che il catalogo si espanderà man mano che verranno realizzate altre applicazioni su Hydra. Alcune di queste topologie sono utilizzate nei progetti di aste basate su Hydra di cui parliamo qui di seguito.

Ulteriori informazioni su Hydra sono disponibili qui.

Analisi commerciale dei progetti d’asta

Nella fase di scoperta di questo progetto, è stata condotta un’analisi aziendale per comprendere meglio lo spazio delle aste su Cardano e il modo in cui può sfruttare la tecnologia di scaling Hydra.

IOG e MLabs hanno intervistato un ampio gruppo di progetti Cardano che realizzano aste e marketplace NFT, da cui è stato selezionato un gruppo più ristretto di quattro progetti per interviste approfondite su:

• le specifiche del loro caso d’uso delle aste
• la loro valutazione dei benefici e dei limiti di Hydra
• le loro preferenze su alcuni compromessi che potrebbero essere necessari nella transizione dei contratti smart L1 per le aste all’ambiente Hydra Head.

Caso d’uso dell’asta in stile inglese

Abbiamo scoperto che c’è un ampio consenso tra gli intervistati sul fatto che l’implementazione di riferimento di questo progetto dovrebbe puntare su un’asta in stile inglese con caratteristiche standard. Tutti gli intervistati hanno intenzione di utilizzare un’asta di questo tipo all’interno delle rispettive piattaforme.

Le caratteristiche principali di un’asta in stile inglese sono le seguenti:

• Un venditore fornisce un prodotto da vendere all’asta (il “lotto d’asta”) - ad esempio un NFT.
• Quando l’asta inizia, gli offerenti possono iniziare a fare offerte, che devono essere superiori al prezzo di partenza definito dal venditore.
• L’offerente vincente deve pagare la sua offerta. Questo può essere garantito richiedendo depositi per ogni offerta, oppure può essere applicato in modo più debole imponendo sanzioni monetarie o di reputazione agli offerenti che non rispettano le loro offerte.
• Durante l’asta, ogni offerente può aumentare la propria offerta di almeno l’incremento minimo definito dal venditore.
  Alla fine dell’asta:
  • l’offerente con l’offerta più alta deve ricevere il lotto d’asta,
  • gli altri offerenti riceveranno il rimborso di eventuali depositi effettuati durante l’asta, e
  • il venditore deve ricevere il ricavato dell’offerta più alta, dopo aver dedotto le spese appropriate.

Altre caratteristiche utili possono essere incluse in un’asta all’inglese:

• Prezzo di acquisto immediato - il venditore può fissare un prezzo al quale il lotto d’asta può essere immediatamente acquistato durante l’asta, ponendo fine all’asta a favore dell’acquirente immediato.
• Popcorn bidding - la scadenza dell’asta può essere prorogata se ci sono offerte ancora in corso in prossimità della scadenza.
• Prezzo di riserva segreto - prima dell’inizio dell’asta, il venditore può fissare un prezzo segreto che deve essere superato dall’offerta più alta per aggiudicarsi l’asta. Al termine dell’asta, il prezzo di riserva viene rivelato e se non viene superato da nessuna offerta, il lotto rimane invenduto.
• Una sequenza di lotti d’asta - quando le offerte si chiudono su un lotto d’asta, gli offerenti possono rimanere nell’asta mentre il lotto successivo della sequenza viene messo all’asta.

Uno degli intervistati sta anche cercando di implementare un’asta in stile olandese, oltre all’asta in stile inglese che utilizzerà in altre parti della sua piattaforma. In un’asta in stile olandese, il prezzo d’asta inizia alto e poi diminuisce automaticamente nel tempo, fino a quando un offerente accetta di acquistare il lotto d’asta al prezzo corrente - vincendo l’asta. Sebbene gli smart contract per un’asta in stile olandese siano diversi da quelli per un’asta in inglese, essi condividono la maggior parte delle limitazioni di Hydra per le aste. Pertanto, un’implementazione di riferimento di un’asta in stile inglese che mitighi adeguatamente le limitazioni di Hydra sarebbe utile anche per l’asta in stile olandese.

In definitiva, la preferenza degli intervistati è quella di dare la priorità a un’implementazione di un’asta basata su Hydra che fornisca le caratteristiche fondamentali dell’asta in inglese e che attenui sufficientemente le limitazioni di Hydra per il caso d’uso dell’asta. Anche le funzionalità aggiuntive sarebbero gradite, ma potrebbero essere aggiunte dai progetti stessi, adattando la nostra implementazione di riferimento alle loro esigenze. Il problema principale che sperano di risolvere è come implementare un’asta inglese funzionale con le caratteristiche principali di Hydra.

Vantaggi e limiti di Hydra per le aste al novembre 2022

Sia nel questionario del sondaggio che nelle interviste approfondite, agli intervistati è stato chiesto quali fossero i vantaggi e i limiti del protocollo Hydra Head per i loro progetti. Nelle interviste approfondite, agli intervistati è stato fornito un briefing standard su Hydra per garantire che fossero adeguatamente informati sul funzionamento della tecnologia quando hanno fornito le loro risposte su benefici e limiti.

Limitazioni di Cardano L1

Gli intervistati hanno individuato i seguenti limiti nell’esecuzione di applicazioni generiche sulla rete principale di Cardano:

• Il throughput delle transazioni è insufficiente per le interazioni ad alta frequenza/volume degli utenti.
• Il tempo di completamento delle transazioni è troppo lento.
• I costi delle transazioni sono troppo elevati.
• La capacità di archiviazione dei dati è troppo bassa per le applicazioni ricche di dati.
• È difficile concatenare in modo affidabile le transazioni tra più partecipanti.

Le prime tre limitazioni incidono particolarmente sulla scalabilità e sulla redditività commerciale dei progetti d’asta su Cardano:

• Il basso throughput delle transazioni può limitare il numero di offerte nelle aste, impedendo loro di raggiungere il prezzo di vendita.
• La lentezza nella finalizzazione delle transazioni può rallentare il ritmo delle aste, riducendo l’eccitazione/il divertimento che gli offerenti provano nel partecipare alle aste.
• Gli elevati costi di transazione possono ridurre i profitti dei venditori e delle case d’asta o aumentare i costi di partecipazione per gli utenti.

Vantaggi di Hydra per le aste

Gli intervistati sperano di ottenere i seguenti vantaggi dall’utilizzo di Hydra nei loro progetti di aste:

• Una maggiore produttività e una più rapida conclusione delle transazioni consentirebbero di aumentare la frequenza delle offerte nelle aste.
• Commissioni di transazione più economiche (possibilmente zero) ridurrebbero i costi per offerenti, venditori e case d’asta.
• Gli smart contract isomorfi consentirebbero un riutilizzo significativo degli smart contract di L1 in L2 e potenzialmente una distribuzione flessibile tra L1 e L2. Ciò potrebbe ridurre i costi di sviluppo e di revisione.

Limiti di Hydra per le aste

Gli intervistati hanno identificato le seguenti limitazioni che attualmente li scoraggiano dal perseguire un’implementazione di un’asta basata su Hydra per conto proprio.

In primo luogo, non è chiaro come eseguire giochi a somma zero all’interno di una testa Hydra. Nel protocollo semplificato della testa (attualmente implementato nel repository GitHub di hydra-poc), ogni partecipante alla testa può in qualsiasi momento porre il veto sull’ulteriore evoluzione della testa di Hydra. Esercitando questo potere di veto, gli altri partecipanti non hanno altra scelta se non quella di chiudere l’Hydra Head a L1 con l’ultimo stato dell’Head che tutti i partecipanti sono riusciti a concordare prima del veto.

Per un’asta condotta all’interno di una singola testa Hydra, questo potere di veto è particolarmente problematico perché può impedire che l’asta abbia offerte riconosciute. Infatti, non c’è alcun incentivo intrinseco per un offerente a firmare le offerte presentate da un altro offerente all’interno della testa dell’idra, perché l’offerta dell’altro offerente aumenta il prezzo che l’offerente dovrebbe pagare per vincere l’asta.

In secondo luogo, solo i partecipanti elencati nell’inizializzazione dell’Hydra Head possono partecipare a un Hydra Head (cioè non possono entrare nuovi partecipanti), e ogni partecipante all’Hydra Head deve rimanere attivo e rispondere agli altri partecipanti affinché l’Hydra Head continui a funzionare (cioè nessun partecipante può andarsene senza chiudere l’Hydra Head per tutti i partecipanti). Questa è una limitazione significativa per le aste a testa singola, perché è altamente auspicabile che nuovi offerenti si uniscano alle aste in corso. Inoltre, gli offerenti preferirebbero non rimanere bloccati in aste a cui non sono più interessati, il che potrebbe persino portarli a esercitare il loro potere di veto per chiudere prematuramente l’Hydra Head - un risultato indesiderabile per le aste a testa singola.

In terzo luogo, i partecipanti all’Hydra Head possono utilizzare solo i fondi che hanno impegnato nell’Hydra Head prima della sua apertura. Questa limitazione esiste nell’attuale implementazione di Hydra (repository hydra-poc), ma sarà eliminata quando gli impegni/disimpegni incrementali saranno implementati più avanti nella roadmap di Hydra. Per ora, questa limitazione limita di fatto il prezzo massimo raggiungibile in qualsiasi asta basata su Hydra che richieda che le offerte siano interamente sostenute dai depositi degli offerenti. Inoltre, rivela l’offerta massima possibile di ciascun offerente, che può essere sfruttata da altri offerenti che hanno più fondi impegnati nella Hydra Head.

Gli intervistati hanno indicato che tutte e tre queste limitazioni dovrebbero essere sufficientemente attenuate perché un’asta basata su Hydra sia un prodotto fattibile da lanciare su Cardano, ma che è particolarmente importante superare la prima limitazione perché possano prendere in considerazione la possibilità di fornire un’asta basata su Hydra sulle loro piattaforme.

Progetti d’asta su una singola testa

Asta di base su testa singola

In questo progetto di base per un’asta a testa singola, il venditore e tutti gli offerenti formano l’insieme dei partecipanti di una testa Hydra che aprono per l’asta. Sono stati presi in considerazione diversi modi per mitigare le limitazioni di Hydra per un’asta a testa singola.

Il potere di veto dei partecipanti con una singola testa d’asta Hydra può essere mitigato da:

• commercializzando le aste a testa singola come un servizio premium che consente di fare offerte più frequenti
• inserendo in queste aste un numero maggiore di prodotti interessanti o di valore.

L’accesso a questo servizio premium verrebbe fornito a utenti sufficientemente controllati da KYC, con un’alta reputazione e un deposito che può essere ridotto dal banditore in caso di comportamento scorretto. Gli offerenti sono incentivati a partecipare in buona fede alle aste a testa singola, per evitare di degradare la loro reputazione, di perdere l’accesso a questo servizio premium e/o di vedersi ridurre il deposito.

Il requisito di essere sempre attivi e reattivi nei confronti di tutti i partecipanti all’interno di una testa Hydra può essere mitigato utilizzando la topologia della testa gestita, in cui il banditore fornisce l’infrastruttura per trasmettere le transazioni e le firme della testa Hydra tra i partecipanti alla testa e persino per eseguire parte del software della testa Hydra per conto dei partecipanti. In questa topologia, i partecipanti mantengono il diritto di negare il consenso a qualsiasi transazione all’interno dell’Hydra Head, ma ora il banditore può potenzialmente censurare la comunicazione tra i partecipanti.

Per mitigare gli effetti del fatto che solo i fondi pre-impegnati sono disponibili nell’asta (prima che gli impegni/disimpegni incrementali diventino disponibili su Hydra):

• Richiedere a tutti gli offerenti di depositare la stessa quantità di fondi nella testa di Hydra, in modo che nessun offerente abbia un vantaggio informativo sugli altri offerenti in termini di capacità di pagamento.
• Utilizzate la funzione “prezzo di acquisto immediato” e impostate tale prezzo sul deposito fisso richiesto agli offerenti per partecipare all’asta. Nessun offerente razionale farebbe comunque un’offerta superiore al prezzo di acquisto immediato, quindi un’asta di questo tipo non sarebbe di fatto condizionata da questa limitazione di Hydra.

Alcuni intervistati hanno indicato che questa variante attenuata del progetto di asta a testa unica potrebbe essere potenzialmente praticabile sulle loro piattaforme.

Asta segreta su testa singola

Questo progetto sarebbe probabilmente utile solo in un’applicazione piuttosto di nicchia di un’asta, ma è stato incluso qui come esempio illustrativo perché tecnicamente può eliminare la maggior parte degli incentivi razionali per un offerente a esercitare il suo potere di veto nei confronti di altri offerenti all’interno di una testa Hydra.

In questo caso, gli offerenti sono tenuti a fissare le rispettive offerte segrete iniziali durante la preparazione dell’asta prima dell’apertura della testa dell’idra. All’apertura della testa dell’idra e fino alla chiusura dell’asta, gli offerenti possono modificare le proprie offerte segrete con nuove offerte, che possono essere inferiori o superiori a quelle precedenti. In questo modo, gli offerenti dovrebbero in generale avere pochi incentivi a porre veti sulle offerte degli altri, perché non sanno se le nuove offerte sono più basse o più alte delle precedenti.

Naturalmente, la segretezza delle offerte in quest’asta è limitata (come limite superiore) dai fondi che ogni offerente impegna nella testa dell’idra. Tuttavia, questa limitazione può essere mitigata con le stesse tecniche utilizzate per la normale asta a testa singola.

Gli intervistati non sono stati particolarmente entusiasti di questo progetto, perché non permette ai partecipanti di sapere qual è l’offerta più alta in qualsiasi momento prima della fine dell’asta e perché non è chiaro quanto sia importante per gli utenti poter modificare le offerte segrete durante un certo periodo di tempo.

Asta a custodia delegata

In questo disegno, un gruppo di delegati prende in custodia il lotto d’asta e i depositi degli offerenti nell’asta. Gli offerenti inviano le loro offerte all’Hydra Head per delega attraverso i delegati, e tutti i delegati devono firmare un’offerta perché questa abbia effetto. Ogni offerta deve essere sostenuta dai fondi dell’offerente all’interno dell’Hydra Head.

Un vantaggio significativo di questo design è che elimina l’obbligo per il venditore e gli offerenti di essere sempre online e di rispondere ai partecipanti dell’Hydra Head affinché l’asta continui a svolgersi. Inoltre, ogni offerente deve solo firmare le offerte che presenta all’asta. Solo i delegati che gestiscono il consenso di Hydra Head per l’asta devono essere online e reattivi durante l’asta e possono essere pagati per fornire questo servizio in modo affidabile.

Gli offerenti possono essere offline e inattivi finché non desiderano fare nuove offerte e la partecipazione del venditore non è necessaria dopo che il lotto d’asta è stato depositato nell’Hydra Head. Questa può essere un’esperienza molto più piacevole per l’utente rispetto alle aste non custodiali basate su Hydra, dove il venditore e gli offerenti devono firmare ogni transazione che ricevono all’interno della loro testa Hydra.

Un altro vantaggio di questo design è che elimina il potere di veto degli offerenti, in quanto questi ultimi non partecipano direttamente all’Hydra Head e quindi non possono negare la loro firma per il consenso sulle offerte degli altri offerenti all’interno dell’asta.

Sfortunatamente, dare in custodia ai delegati il lotto d’asta e i depositi degli offerenti permette ai delegati di colludere per sottrarre questi fondi all’asta. Gli utenti potrebbero essere riluttanti a vendere NFT di alto valore o a partecipare con depositi elevati a un’asta con custodia. Lo stesso servizio di casa d’aste può trovarsi ad affrontare ulteriori oneri normativi e potenziali responsabilità legali se gestisce aste in custodia.

Alcuni intervistati non erano favorevoli all’esecuzione di aste custodiali su Hydra, sostenendo che queste aste non sono molto diverse dall’esecuzione di aste Web2 tradizionali. Altri intervistati hanno dichiarato che potrebbero prendere in considerazione la gestione di aste con custodia se i miglioramenti nell’esperienza dell’utente superassero gli svantaggi della custodia.

Buono d’asta

Questo progetto è descritto sul sito web di Hydra. Non impone il pagamento dell’offerta vincente, ma consente agli offerenti di fare offerte che superano i fondi che hanno rispettivamente impegnato nella testa di Hydra.

Il banditore forgia e distribuisce a ogni offerente un " token di offerta" NFT che gli consente di fare offerte all’interno della testa Hydra dell’asta. L’asta procede secondo le regole standard in stile inglese, senza richiedere depositi di offerte, e l’offerente vincente riceve un buono su L1 alla chiusura dell’asta. L’aggiudicatario può scegliere di riscattare il suo buono in cambio del lotto d’asta su L1, pagando l’importo dell’offerta vincente.

Uno dei principali vantaggi di questo progetto d’asta è che richiede pochissime transazioni per aprire e chiudere l’Hydra Head, con conseguenti costi di setup molto bassi e la possibilità di supportare un maggior numero di partecipanti all’Hydra Head:

• Solo i token di offerta devono essere depositati in Hydra Head durante la fase di commit. I fondi dell’offerente e il lotto d’asta del venditore rimangono fuori da Hydra Head, anche se il lotto d’asta deve essere bloccato da uno smart contract in modo da poter essere riscattato dal voucher.
• L’unica transazione di pagamento necessaria alla chiusura di Hydra Head è il pagamento del voucher al vincitore dell’asta su L1.

Il riscatto del buono è facoltativo per l’offerente vincitore, il che significa che il venditore non ha la garanzia di essere pagato dall’asta. Inoltre, permette agli offerenti di fare offerte frivole e irragionevolmente alte che non intendono onorare, interferendo con gli offerenti onesti e potenzialmente sabotando completamente l’asta.

Un modo per attenuare il problema delle offerte insincere è quello di richiedere a ogni offerente di versare una cauzione che sia deducibile dal prezzo di aggiudicazione se l’offerente vince e altrimenti rimborsabile se l’offerente perde. Se l’offerente vince ma non riscatta il suo buono, il venditore trattiene il deposito deducibile. Il deposito deducibile può eliminare l’incentivo razionale degli offerenti a fare offerte insincere, a meno che il loro profitto dalle offerte insincere non superi la franchigia.

Il problema delle offerte insincere nell’asta a voucher può essere ulteriormente attenuato nello stesso modo in cui il potere di veto degli offerenti è attenuato nell’asta a testa unica di base. Se l’asta di voucher è commercializzata come un servizio premium accessibile solo agli utenti con KYC e reputazione elevata, gli utenti possono evitare di fare offerte insincere se il disconoscimento dell’offerta vincente comporta una sanzione reputazionale sufficientemente grave per la piattaforma. In effetti, secondo uno degli intervistati, che partecipa regolarmente alle aste NFT basate su Discord, il rischio di una sanzione reputazionale è di solito sufficiente a far sì che gli offerenti vincitori onorino le loro offerte.

Asta a voucher delegata

Questo progetto combina l’asta a voucher con una testa Hydra gestita da delegati. In questo modo si attenua il rischio che i delegati possano colludere per rubare direttamente i fondi al venditore e/o agli offerenti, perché il lotto d’asta e i fondi degli offerenti rimangono al di fuori della Hydra Head.

L’asta in questo progetto funziona allo stesso modo dell’asta con voucher, tranne per il fatto che gli offerenti inviano le loro offerte all’asta per procura attraverso i delegati della testa di Hydra, e la firma multipla dei delegati è necessaria affinché le offerte influenzino lo stato dell’asta all’interno della testa di Hydra. Alla chiusura dell’asta, l’offerente vincente riceve un voucher che può essere riscattato per il lotto d’asta su Cardano L1.

Questo progetto d’asta eredita i vantaggi di comodità per l’utente dall’asta con custodia delegata ed eredita i bassi costi di configurazione di Hydra Head e l’alta capacità degli offerenti dall’asta con voucher. Inoltre, con impegni/disimpegni incrementali, i delegati possono inviare il voucher al vincitore di un’asta e poi riutilizzare i token di offerta per i nuovi offerenti in un’asta successiva, senza chiudere l’Hydra Head. In questo modo, i delegati possono avere un modello di business redditizio gestendo una testa persistente e affittando il tempo sulla testa Hydra a varie aste.

Come nell’asta a voucher semplice, il problema delle offerte insincere può essere mitigato richiedendo a ogni offerente un deposito che è deducibile dal prezzo di aggiudicazione se l’offerente vince e riscatta il lotto d’asta, rimborsabile se l’offerente perde e incamerato dal venditore se l’offerente vince e non riscatta il lotto d’asta.

Una differenza sostanziale tra questo progetto e l’asta a voucher semplice è che gli offerenti non partecipano più direttamente alla testa Hydra. Ciò significa che le firme degli offerenti non sono necessarie per autorizzare alcuna transizione di stato all’interno di Hydra Head, e quindi i delegati possono autorizzare transazioni che dichiarano falsamente offerte che gli offerenti non hanno presentato. Naturalmente, l’offerente vincente può scegliere di non onorare tale offerta falsa; tuttavia, se il requisito del deposito deducibile è stato incluso nell’asta per combattere le offerte insincere, l’offerente vincente dovrebbe incamerare il suo deposito quando rifiuta un’offerta falsa. Ad esempio, i delegati potrebbero colludere con il venditore per dividere il deposito incamerato dall’aggiudicatario.

Per eliminare il rischio di offerte false da questo progetto, ogni transazione d’offerta all’interno della testa Hydra potrebbe produrre un dato UTXO che include la firma dell’offerente per quell’offerta, e la firma dell’offerente vincente dovrebbe essere conservata nei dati fino all’emissione del voucher all’offerente vincente su L1. Il voucher sarebbe valido solo se il suo dato UTXO contiene la firma valida dell’offerente per l’offerta corrispondente; in caso contrario, il voucher non sarebbe valido e l’esito dell’asta verrebbe annullato.

Un altro rischio che emerge dall’affidare ai delegati l’esecuzione dell’asta all’interno di Hydra Head è che essi possano truccare l’asta in modo che un’offerta diversa da quella più alta vinca l’asta. Tuttavia, i delegati andrebbero incontro a significative penalizzazioni in termini di reputazione per aver agito in questo modo, il che comprometterebbe la loro capacità di continuare a offrire servizi di auction-hosting in futuro.

Un’ulteriore attenuazione del rischio di manipolazione delle aste da parte dei delegati consisterebbe nell’imporre loro di conservare una copia del registro delle transazioni d’asta della testa dell’idra che hanno portato al particolare esito dell’asta che è stato finalizzato su L1. Questa copia del libro mastro dell’asta potrebbe anche essere archiviata per un periodo di tempo sufficiente su blockchain ottimizzate per lo storage (ad esempio Arweave) o su soluzioni L2 (ad esempio Logosphere). Se un offerente contesta l’esito dell’asta con un’accusa di manipolazione dell’asta, i delegati potrebbero presentare il registro dell’asta come prova in un processo di risoluzione delle controversie fuori dalla catena.

Complessivamente, questo progetto raggiunge il giusto equilibrio tra il design dell’asta delegata e quello dell’asta a voucher.

Modelli d’asta su reti di Hydra Heads

Asta a forma di stella

Questo progetto utilizza la topologia della rete di teste a stella descritta sul sito web di Hydra. In questo caso, un banditore centralizzato apre una testa separata a coppie con ogni offerente nell’asta. L’offerente impegna nella testa Hydra i fondi che desidera utilizzare nell’asta, mentre il banditore non impegna alcun fondo nella testa Hydra, ma si limita a testimoniare e a marcare con la propria firma le offerte dell’offerente. Il banditore può decidere di addebitare una tariffa per fornire questo servizio agli offerenti dell’asta.

Il caso d’uso dell’asta può essere implementato sulla topologia di rete Hydra a forma di stella senza richiedere trasferimenti di fondi tra le teste tramite contratti hash time-locked (HTLC). Invece, al termine dell’asta, ogni testa a coppie viene chiusa con l’offerta più alta del suo offerente riportata a Cardano L1 e quindi l’offerta vincente può essere risolta in modo efficiente durante il fanout da ogni testa. Potenzialmente, potrebbe esistere un meccanismo per risolvere le offerte perdenti all’interno delle teste Hydra durante l’asta, consentendo agli offerenti perdenti di uscire dall’asta in anticipo se non desiderano più continuare a fare offerte.

I principali vantaggi dell’asta a stella rispetto all’asta a testa singola sono:

• Nessun potere di veto degli offerenti. Gli offerenti non possono più porre il veto sulle reciproche offerte perché sono distribuiti in teste d’asta separate.
• Banditore non custode. Il banditore in queste teste Hydra a coppie non può rubare i fondi degli offerenti, perché la firma di ogni offerente è richiesta per ogni transazione nella sua rispettiva testa.
• Requisiti di reattività meno rigidi. Gli offerenti non devono essere sempre attivi e reattivi all’interno delle loro teste Hydra, perché il banditore stesso non invia mai le sue transazioni nelle teste Hydra e quindi non aspetta mai che gli offerenti firmino le sue transazioni. Se un offerente va offline per un po’, il banditore può tranquillamente rimanere inattivo finché l’offerente non si riconnette.

Al contrario, poiché la firma del banditore è richiesta anche per ogni testa a due, il banditore ha il potere di truccare l’asta:

• Censura. Il banditore può impedire a un offerente di fare offerte rifiutandosi di firmare le sue offerte, truccando l’asta a sfavore di quell’offerente e a favore degli altri offerenti che il banditore non sta censurando. Questo è simile al potere di veto dell’offerente nell’asta a testa singola, ma è detenuto solo dal banditore nell’asta a stella.
• Collusione per disonorare un’offerta. Il banditore può consentire a un offerente di disonorare le proprie offerte, in questo modo
  • permettendo all’offerente di sostituire la sua offerta con una più bassa durante l’asta; oppure
  • non contestando il tentativo dell’offerente di chiudere il testa a coppia con un’offerta diversa da quella più alta che l’offerente ha fatto nel testa a idra durante l’asta.
• Collusione per fare offerte segrete. Il banditore può consentire a un offerente di fare segretamente un’offerta più alta di quella che è stata trasmessa fino a quel momento a tutti gli offerenti. Ciò significa che gli altri offerenti si sbaglieranno su quale sia l’offerta più alta e su chi sia il miglior offerente fino alla chiusura dell’asta o fino a quando l’offerente segreto non si rivelerà come il miglior offerente.

I due poteri di collusione del banditore non esistono nell’asta a testa singola. Nell’asta a testa unica un offerente non può disonorare le sue offerte perché il venditore non firmerebbe una transazione che abbasserebbe l’offerta corrente dell’offerente. Un offerente non può fare offerte segrete nell’asta a testa singola, perché ogni partecipante all’Hydra Head deve vedere e firmare l’offerta perché questa abbia effetto. Pertanto, il potere di collusione centralizzato del banditore nell’asta a stella è il suo principale svantaggio rispetto all’asta a testa singola.

Asta con schema a costellazione

Questo progetto è una generalizzazione dell’asta a stella che divide il banditore in più parti neutrali nella testa di ogni offerente. Inoltre, richiede solo M di N parti neutrali (M < N) per firmare le transazioni all’interno della testa dell’offerente, oltre alla firma dell’offerente stesso.

Ad esempio, supponiamo che Alice, Bob e Charlie siano offerenti in un’asta e che Oskar, Patricia, Quentin, Rupert e Sally siano potenziali parti neutrali. Se impostiamo (M = 2) e (N = 3), potremmo impostare le teste di idra degli offerenti per l’asta come segue:

• La testa di Alice comprende Alice, Oskar, Quentin e Rupert. Ogni transazione in questa testa richiede la firma di Alice e 2 delle 3 firme di Oskar, Quentin e Rupert.
• La testa di Bob comprende Bob, Patricia, Rupert e Sally. Ogni transazione in questa testa richiede la firma di Bob e 2 delle 3 firme di Patricia, Rupert e Sally.
• La testa di Charlie comprende Charlie, Oskar, Patricia e Sally. Ogni transazione in questa testa richiede la firma di Charlie e 2 delle 3 firme di Oskar, Patricia e Sally.

Questo design attenua il potenziale di manipolazione centralizzata dell’asta a stella:

• La collusione con l’offerente per disonorare o non rivelare un’offerta è ridotta perché l’offerente deve colludere con più parti neutrali per truccare collettivamente l’asta a suo favore.

•  D'altra parte, lo schema di firma M di N rende più facile la collusione dell'offerente con le parti neutrali rispetto al consenso unanime, quindi M non dovrebbe essere molto inferiore a N.
  

• La censura delle offerte è ridotta perché richiede che (N - M + 1) parti neutrali rifiutino di firmare un’offerta.

Inoltre, lo schema di firma M di N può allentare i requisiti di reattività delle parti neutrali, perché fino a (N - M) parti neutrali possono andare brevemente offline senza necessariamente impedire che un’offerta venga firmata più volte nella testa Hydra.

Potremmo anche rinunciare alla selezione casuale delle parti neutrali per la testa Hydra di ogni offerente, utilizzando invece un gruppo fisso di parti neutrali indipendenti in ogni testa. Ad esempio, potrebbe trattarsi di una federazione di case d’asta indipendenti che si mantengono reciprocamente oneste nelle aste che ospitano per gli utenti.

Per ridurre ulteriormente il potenziale di manipolazione delle aste da parte delle parti neutrali, queste possono essere selezionate casualmente per ogni testa di offerente da un ampio pool di potenziali parti neutrali, forse in modo simile alla lotteria basata su funzioni casuali verificabili (VRF) utilizzata su Cardano L1 per selezionare i leader degli slot per aggiungere blocchi alla catena.

In un certo senso, questa lotteria Hydra Head potrebbe essere vista come una naturale generalizzazione della lotteria degli slot leader di Cardano da L1 a L2. Nel primo livello, gli slot leader vengono selezionati in modo casuale per aggiungere blocchi di transazioni firmate dagli utenti alla catena principale. Nel secondo livello, le parti neutrali sono selezionate casualmente per mediare le transazioni transitorie all’interno di una Hydra Head e poi per contribuire a riportare il risultato finale alla catena principale. In effetti, l’ampia rete di stake pool di Cardano potrebbe essere sfruttata per fornire anche servizi di parti neutrali sul livello 2, come ulteriore flusso di entrate che sfrutta le loro risorse informatiche esistenti.

Il progetto d’asta basato su Hydra selezionato per la fase di implementazione

Per la fase di implementazione di questo progetto, è stato scelto il design di asta a voucher delegati perché attenua in modo significativo le tre principali limitazioni del protocollo Hydra Head che, secondo gli intervistati, li scoraggiano dal perseguire soluzioni basate su Hydra. In base alla nostra analisi commerciale, l’implementazione di riferimento basata su questo progetto potrebbe essere adattata in modo fattibile a un servizio d’asta sulla rete principale di Cardano.

Inoltre, questo progetto può dimostrare alla comunità di Cardano che, se si supera il modello di base a testa singola, una più ampia gamma di casi d’uso diventa fattibile applicando tecniche quali:

• Gestione delle informazioni piuttosto che dei fondi all’interno di una Hydra Head (ad esempio, buoni riscattabili).
• Delegare gli obblighi di partecipazione a Hydra per ridurre l’onere e la scomodità per l’utente.

Per quanto riguarda i progetti di asta a forma di stella e di schema a costellazione, si tratta di progetti interessanti che hanno incuriosito gli intervistati. Tuttavia, sono anche significativamente più complessi del progetto dell’asta di voucher delegati. Inoltre, richiedono la disponibilità di funzioni di Hydra Head non ancora implementate, affinché i vantaggi di questi progetti siano evidenti in una dimostrazione dell’implementazione di riferimento. Pertanto, si raccomanda di prenderli in considerazione per un futuro progetto d’asta basato su Hydra, forse anche da parte di alcuni dei partecipanti all’analisi aziendale, se il nostro progetto attuale dà loro la certezza di poter portare avanti i propri progetti di DApp basati su Hydra.

Oggetto della fase di implementazione

Nella fase di implementazione, IOG e MLabs daranno priorità all’implementazione delle sole caratteristiche principali dell’asta in stile inglese all’interno del progetto dei voucher delegati. Una volta implementate, le altre caratteristiche dell’asta in stile inglese potranno essere perseguite come caratteristiche “da avere”. La ragione di questa priorità è che i partecipanti e gli intervistati nell’analisi aziendale hanno indicato che preferiscono vedere le limitazioni di Hydra adeguatamente risolte per il caso d’uso dell’asta, supervisionando le funzionalità non essenziali implementate nell’asta basata su Hydra.

Al termine di questa fase, l’implementazione dell’asta dovrebbe fornire le seguenti funzionalità:

• Un gruppo di delegati può aprire una testa Hydra in grado di ospitare un’asta per un asset NFT fornito da un venditore.
• Il venditore può distribuire il diritto di partecipare all’asta (ad esempio tramite token di partecipazione) ai potenziali offerenti che hanno bloccato i loro depositi deducibili per l’asta.
• Ogni offerente può presentare un’offerta all’asta inviandola a uno dei delegati, che la trasmetterà al resto dei delegati.
• I delegati possono confermare collettivamente le offerte con una firma multipla tramite il protocollo Hydra Head, includendo così le offerte nello stato del ledger di Hydra Head.
• Allo scadere del termine dell’asta, i delegati possono risolvere in modo deterministico le offerte all’interno dell’Hydra Head per determinare l’offerta vincente.
• I delegati possono chiudere l’Hydra Head:
  • Se l’asta viene risolta, può essere emesso un voucher per l’offerente vincente, che gli consente di riscattare l’attività NFT del venditore in cambio dell’importo dell’offerta.
  • Se l’asta non viene risolta, le offerte possono essere regolate su L1 per determinare l’offerta vincente e quindi il voucher può essere emesso all’offerente vincente.
• Gli offerenti perdenti possono riscattare i loro depositi deducibili quando l’Hydra Head dell’asta si chiude e l’asta viene risolta.
• L’offerente vincente può utilizzare i fondi del suo deposito deducibile per pagare il bene NFT al venditore.
• Quando il voucher viene emesso all’aggiudicatario, viene fissata una scadenza per riscattare il bene NFT del venditore. Se l’aggiudicatario non riscatta il bene NFT del venditore entro la scadenza, il venditore può richiedere il deposito deducibile dell’aggiudicatario.
• Il voucher UTXO può essere speso solo dall’offerente vincente per riscattare il NFT del venditore o dal venditore per richiedere il deposito deducibile dell’offerente vincente dopo la scadenza del termine di riscatto.

Svilupperemo inoltre una specifica tecnica per migliorare l’implementazione di cui sopra con offerte firmate dall’offerente, in base alla quale:

• Gli offerenti firmano il contenuto delle loro offerte (ID dell’asta, importo dell’offerta, ora dell’offerta) quando si presentano all’asta.
• La firma di ogni offerta da parte dell’offerente viene conservata all’interno di un dato UTXO sul ledger di Hydra Head, finché l’offerta è attiva nell’asta.
• Un buono valido può essere emesso solo in un UTXO che contiene la firma dell’offerta dell’offerente vincente nel suo dato. * Solo un voucher valido può essere utilizzato per riscattare l’attività NFT del venditore.

Potenziali miglioramenti futuri dell’implementazione dell’asta

L’implementazione dell’asta di cui sopra risolve in modo significativo le tre principali limitazioni di Hydra Head per il caso d’uso dell’asta. Tuttavia, potrebbero essere apportati diversi ulteriori miglioramenti per renderla ancora più adatta a un prodotto reale. Non ci impegniamo a implementarli nell’ambito di questo progetto, ma li menzioniamo qui e continueremo a pensare ad altri miglioramenti, in modo che i futuri sviluppatori possano avere una visione chiara di come realizzare la migliore asta basata su Hydra per i loro utenti.

L’implementazione dell’asta richiederà le firme degli offerenti per autorizzare le offerte, per impedire ai delegati di falsificare le offerte, ma non può impedire ai delegati di truccare collettivamente l’asta in modo che l’offerta più alta non vinca l’asta. Un miglioramento futuro dell’implementazione dell’asta sarebbe quello di fornire strumenti che preservino il ledger Hydra Head dei delegati sulle transazioni d’asta, per facilitare la risoluzione delle controversie fuori dalla catena con il venditore e gli offerenti. Inoltre, forse ulteriori informazioni (ad esempio una prova ZKP) derivate dal libro mastro di Hydra Head potrebbero essere riportate a L1 durante il regolamento dell’asta e l’emissione dei voucher.

Un altro miglioramento dell’asta consisterebbe nel permettere a Hydra Head di rimanere aperto mentre l’esito di un’asta viene regolato in L1 e un’altra asta viene inserita per l’offerta. Ciò richiederebbe probabilmente la funzione di commit/de-commit incrementale prevista nella roadmap del protocollo Hydra Head.

Un terzo miglioramento dell’asta consisterebbe nel permettere a ogni offerente di bloccare unilateralmente i propri fondi su L1 come depositi ad hoc per l’asta, fornendo poi la prova di questi fondi bloccati quando si presentano le offerte all’interno dell’asta. Questi depositi variabili potrebbero fornire una garanzia completa per tutte le offerte nell’ambito dell’asta, eliminando così la necessità di un deposito iniziale fisso deducibile da parte di ciascun offerente.

Infine, l’implementazione dell’asta potrebbe essere migliorata consentendo l’allentamento della soglia di consenso dei delegati per alcune aste, passando dall’unanimità a uno schema di firme M su N. Questo renderebbe l’asta più robusta contro i rischi di un’eventuale perdita di valore. Questo renderebbe l’asta più robusta contro la perdita della connessione da parte di un singolo delegato o il sabotaggio doloso della testa Hydra, anche se sarebbe leggermente meno sicura di una soglia di consenso unanime contro la collusione collettiva dei delegati contro il venditore e/o gli offerenti.

Miglioramenti suggeriti al protocollo Hydra Head per facilitare ulteriormente le aste

Mentre IOG e MLabs esploravano lo spazio di progettazione per le aste basate su Hydra, ci si è resi conto dell’importanza di alcune caratteristiche del protocollo Hydra Head per facilitare la progettazione di aste migliori. Alcune di queste sono già presenti nella roadmap di Hydra Head come funzionalità pianificate, mentre altre sono nuove funzionalità che abbiamo scoperto durante il brainstorming dei progetti d’asta.

La seguente caratteristica non è ancora stata implementata nel protocollo Hydra Head, ma è sulla tabella di marcia:

• Il commit/de-commit incrementale di UTXO in una Hydra Head consentirebbe di progettare DApp che utilizzano Hydra Head di maggiore durata. Per le aste, invece di aprire e chiudere una Hydra Head (o una rete di Hydra Head) ogni volta che viene ospitata un’asta, le stesse Head potrebbero essere mantenute in funzione, con i risultati di ogni asta disimpegnati nella catena principale e gli UTXO per l’asta successiva impegnati nella Hydra Head.
  • Questa funzione sarebbe vantaggiosa per le aste senza voucher, che consentono agli offerenti di fare offerte solo con i fondi che hanno impegnato nella testa Hydra durante l’inizializzazione. Gli impegni/disimpegni incrementali consentirebbero agli offerenti di aumentare tali fondi durante l’asta, permettendo loro di fare offerte più alte.
  • Questa funzione sarebbe vantaggiosa anche per l’asta dei voucher delegati, in quanto permetterebbe alla testa Hydra di rimanere aperta mentre chiude un’asta (inviando il voucher al vincitore su L1) e si prepara a ospitare l’asta successiva.

Le seguenti caratteristiche dovrebbero essere prese in considerazione per la roadmap di Hydra Head, in quanto faciliterebbero alcune proprietà desiderabili per le aste e le DApp simili costruite su Hydra:

• appartenenza dinamica all’interno di una Hydra Head. In particolare per le aste, i partecipanti dovrebbero essere in grado di entrare e uscire liberamente dall’Hydra Head, quando non sono obbligati a rimanere come il miglior offerente dell’asta. Se i partecipanti si sentono bloccati all’interno di una testa Hydra, potrebbero essere incentivati a chiudere la testa Hydra per poterne uscire. Se invece potessero andarsene con grazia, senza chiudere la testa per gli altri partecipanti, sarebbe un miglioramento della UX dell’applicazione.
  • Questa funzione sarebbe utile per la maggior parte delle aste, in particolare per quelle in cui gli offerenti partecipano direttamente alle Hydra Heads.
• Ruolo di parte neutrale in una testa Hydra, con soglia di firma M di N per le parti neutrali. Come spiegato nel progetto dello schema di costellazione, questa funzione ci permetterebbe di dividere una parte fidata centralizzata all’interno di una testa Hydra (ad esempio il banditore in un’asta a stella) in un gruppo di parti neutrali, calibrando al contempo la robustezza contro la collusione e la censura da parte delle parti neutrali.
  • Questa caratteristica sarebbe vantaggiosa per la progettazione di aste con schema a costellazione. Può essere utile anche per i progetti di aste delegate, dove una soglia di firma M su N può migliorare la robustezza contro la perdita della connessione da parte di un singolo delegato o il sabotaggio della testa dell’idra con l’omissione della sua firma.

Delle caratteristiche sopra elencate, solo il commit/de-commit incrementale migliorerà sostanzialmente l’asta di voucher delegati che abbiamo scelto per l’implementazione. Le altre caratteristiche amplificherebbero l’efficacia dei progetti alternativi che abbiamo considerato.