Scopri le liste di controllo per l’usabilità della blockchain

Innanzitutto, per aiutare le catene di censura resilienti, immutabili e senza autorizzazione a ottenere un’ampia adozione nel mercato, è necessario apportare molte modifiche. Pertanto, ogni strato dell’ecosistema deve essere più utilizzabile dal protocollo di base. Tutto questo fino all’interfaccia utente finale.

Allo stesso modo, questi livelli devono sfruttare le proprietà e l’usabilità della blockchain in modo che possa aver luogo un’adozione più che significativa. E questo va risolto, perché poi l’uso della blockchain non può servire. E non può servire se detta blockchain è resistente alla censura e allo stesso tempo l’interfaccia sta censurando.

Livelli di astrazione blockchain

Gli strati esistono come meccanismo di isolamento, ovvero ciascuno degli strati funziona indipendentemente l’uno dall’altro. Vale a dire, lo strato superiore, non dovresti preoccuparti di cosa potrebbe accadere sotto di esso. Allo stesso modo, questo concetto è ciò che viene chiamato astrazione completa.

Pertanto, l’astrazione completa è una pratica evolutiva moderna fondamentale. Alcuni anni fa, gli sviluppatori che programmavano bracci robotici dovevano conoscere il tipo di comunicazione che un hardware aveva con l’altro. Ora, oggi puoi trovare API comuni, questo perché potrebbe esserci un riutilizzo del codice.

Ciò si traduce in uno sviluppo dell’applicazione e in altre varianti di programmazione più rapidamente. Tuttavia, le prestazioni sono un po’ sacrificate, ma la velocità è maggiore. E questo principio si applica esattamente alla blockchain.

Pertanto, il design degli strati inferiori può avere un impatto rispetto all’usabilità degli strati dello strato superiore. Allo stesso modo, senza una base sicura e solida, qualsiasi cosa negli strati superiori sarà instabile se non del tutto. Quindi gli utenti non si fideranno di un protocollo se la sua crittografia viene violata.

Contesto di usabilità della blockchain

Innanzitutto, e prima di poter determinare cosa rende utilizzabile la blockchain, dobbiamo comprendere gli obiettivi specifici del protocollo. Quindi, se è stato sviluppato un protocollo solo per il monitoraggio e la gestione dei patrimoni per il mercato notturno delle banche; allora detto protocollo può essere autorizzato.

Sebbene questo protocollo sia destinato a infrastrutture senza autorizzazioni per risorse non fungibili, i requisiti di usabilità sono molto diversi.

Il basso tempo di transazione per la finalità, l’elevata velocità di transazione e i bassi costi di transazione sono considerati da molti essenziali per qualsiasi blockchain. Tuttavia, la realtà è che sono indipendenti dalla facilità d’uso, tutto a seconda degli obiettivi del protocollo stesso.

Allo stesso modo, accade con le regole del consenso. Cioè, una blockchain non ha bisogno di essere tollerante agli errori bizantini, questo se la rete è autorizzata o federata. Ora, se hai già tutto questo in mente, allora capirai che sono stati discussi solo gli attributi di usabilità comuni che possono essere importanti in obiettivi diversi.

Si parte dal basso

Innanzitutto, partendo dal basso, puoi assicurarti che i livelli siano costruiti sopra. Questi avranno la capacità di ereditare funzioni di usabilità che sono state integrate nativamente con il protocollo di base. In altre parole, ciò che viene creato qui, nel protocollo di base, influenzerà sia gli sviluppatori che gli utenti finali.

 Alcune caratteristiche che un protocollo dovrebbe includere

Per cominciare, è improbabile che tutti gli utenti di un protocollo interagiscano con la blockchain utilizzando un nodo completo. Pertanto, è più comune utilizzare un servizio di nodo ospitato. Ora, se utilizzi test SPV o thin client, gli utenti possono convalidare e inviare le transazioni in modo indipendente e senza doversi fidare degli altri.

Ora, è noto che il modello UTXO ti offre molti vantaggi, il modello basato sull’account è più facile da usare. Poiché esiste un solo account in modo «canonico», il che rende più semplice la gestione dell’account.

Allo stesso modo, è stabilito che un sistema di consenso asincrono e deterministico può avere al massimo due di queste tre proprietà: sicurezza; dove i risultati sono validi e identici in tutti i nodi. Vita; che sono nodi che non sempre falliscono e tolleranza agli errori; il sistema può sopravvivere al guasto del nodo in qualsiasi momento.

Infine, deve essere chiaro che nessun meccanismo di consenso può avere tutte e tre le caratteristiche. Pertanto, qualsiasi sistema di consenso e che sia distribuito in Internet, deve sacrificare una di queste caratteristiche. Pertanto, gli sviluppatori devono determinare ciò che apprezzano e in che modo influisce sull’esperienza dell’utente.

Funzionalità per i manutentori di rete

Una delle caratteristiche principali è quella di dare incentivi full node. Pertanto, dovrebbero esserci motivi per gli utenti per eseguire nodi completi. E questo perché la rete concede loro le autorizzazioni o perché la rete ha un incentivo economico alla crittografia che può concedere. Senza nodi completi, le reti sono meno sicure.

Pertanto, gli incentivi devono coprire le caratteristiche più importanti di qualsiasi protocollo. Ad esempio, nel consenso Bitcoin, viene premiato il miner che sfrutta il blocco sulla catena più lunga. Non ci sono però incentivi per chi propaga i blocchi. Questo è noto come «estrazione egoistica».

Inoltre, dovrebbero essere coperti i dettagli dell’implementazione. Questo perché ci sono molti modi per implementare le specifiche per un protocollo, o un insieme di esse. Pertanto, gli sviluppatori devono aver cura di verificare alcuni casi di sicurezza, questo in modo che non siano bersaglio di attacchi informatici.

Devi bilanciare le visioni

Infine, e come avrete potuto leggere in tutto l’articolo, lo sviluppo esterno dei protocolli è fondamentale, ma deve essere bilanciato con la visione del progetto. Pertanto, è necessario che un progetto abbia i suoi obiettivi chiari in modo che possa garantire che tutti gli sviluppi nella comunità degli utenti abbiano una guida.

Nel frattempo, c’è un dibattito tra fidarsi dei portafogli dell’organizzazione o di terze parti. Ci sono anche disaccordi tra gli sviluppatori che sono open source e altri che non lo sono. Pertanto, dobbiamo continuare a chiarire le domande e continuare a lavorare insieme.