Il team di sviluppo procede con il proprio lavoro per raggiungere il primo obiettivo, la Testnet. La fase 1 si conclude questa settimana con gli ultimi task previsti. Ci troviamo nella fase 2, nella quale lo sviluppo del DAG continua. Questa fase si compone di 2 settimane di sviluppo che ci permetteranno di poter passare alla fase 3, la fase di test conclusiva.

A tal proposito è doveroso fare un appunto tecnico, in quanto nello studio di fattibilità erano state menzionate due soluzioni: per la mainchain oltre al DAG c’era la strada di una blockchain trazionale compatibile con il concetto del POI. In queste due settimane abbiamo studiato nuovamente ed attentamente entrambe le soluzioni, con i pro ed i contro che queste soluzioni presentavano per il nostro progetto.
Siamo arrivati ad un punto in cui, se avessimo proseguito con la prima soluzione dovevamo essere sicuri di farlo non tornando più indietro, per far si che la tabella di marcia non fosse compromessa.

Nel dettaglio la soluzione scelta ci garantisce dei PRO importanti:

PRO
• Non sono previsti elementi esterni alla infrastruttura, poiché anche i nodi che convalidano e
firmano le transazioni sono “inclusi” nella net (a differenza di una blockchain che necessita di miners).
• E possibile realizzare un sistema di 0-fee poiché ogni nodo vede validare almeno n transazioni prima di vedersi convalidate le proprie.
• È possibile (in teoria) creare un mercato delle fee per la convalida.

• Visto il meccanismo di convalida si ha un buon grado di scalabilità all’aumentare del numero dei
nodi (con l’aumentare del numero dei nodi aumentano il numero delle transazioni validate).

CONTRO
• Necessita di introdurre dei meccanismi di protezione in caso di riduzione del volume delle transazioni per evitare attacchi (iota implementa i co-ordinator)

I vantaggi della blockchain in generale li conosciamo tutti, adattando il concetto alla nostra realtà e al progetto per il quale stiamo lavorando abbiamo dei contro importanti e spesso vincolanti:

CONTRO
• Necessita di un algoritmo di consenso (like POW/POS), nel nostro caso MTV non è minabile in quanto totalmente pre-mined. Inoltre è necessaria la creazione di un nuovo algoritmo ASIC resistant poiché nel caso di algoritmi POW si potrebbe essere facilmente esposti ad attacchi al 51% di hash rate.

Algoritmi di staking tipo POS sono comunque da escludere vista l’assenza di un reward.

• Elevati consumi di energia per il mining, in particolar modo nel caso di consenso basato su POW.

Informiamo quindi la community che il team di sviluppatori proseguirà utilizzando la soluzione DAG. Come da richiesta del board si è provveduto a sostituire il precedente sistema di generazione key pair/address con lo standard BIP38 (ad oggi utilizzato da molte blockchain) al fine di aumentare la compatibilità con il mondo crypto ed eventuali wallet hardware o software.

Lo standard BIP 38 offre un elevato grado di univocità degli address ed include vocabolari multilingua.

A breve verrà data alla community la possibilità di interagire/confrontarsi direttamente con il Project Manager per mezzo di Q&A.

In conclusione, vi annunciamo con piacere che ad oggi lo sviluppo procede senza intoppi e senza ritardi sulla tabella di marcia.

Grazie per il vostro supporto, stay tuned!