Non, lanzar unha aplicación descentralizada (dapp) na cadea de bloques non levará a un negocio exitoso. De feito, a maioría dos usuarios nin sequera pensan se a aplicación se executa na cadea de bloques: simplemente elixen un produto máis barato, rápido e sinxelo.

Desafortunadamente, aínda que a cadea de bloques teña as súas propias características e beneficios únicos, a maioría das aplicacións que se executan nel son moito máis caras, máis lentas e menos intuitivas que os seus competidores centralizados.

Moitas veces nos libros brancos das aplicacións que están construídas na cadea de bloques, podes atopar un parágrafo que di: "A cadea de bloques é cara e non pode soportar o número necesario de transaccións por segundo. Afortunadamente, moitas persoas intelixentes están a traballar para escalar a cadea de bloques e no momento en que se lance a nosa aplicación farase bastante escalable".

Nun parágrafo sinxelo, un programador de dapp pode renunciar a unha discusión máis profunda sobre problemas de escalabilidade e solucións alternativas aos problemas. Isto adoita levar a unha arquitectura ineficiente onde os contratos intelixentes que se executan na cadea de bloques serven como backend e núcleo da aplicación.

Non obstante, aínda hai enfoques sen probar para a arquitectura de aplicacións descentralizadas que permiten unha escalabilidade moito mellor ao reducir a dependencia da cadea de bloques. Por exemplo, Blockstack está a traballar nunha arquitectura onde a maioría dos datos e a lóxica da aplicación se almacenan fóra da cadea.

Vexamos primeiro un enfoque máis tradicional, que utiliza a cadea de bloques como intermediario directo entre os usuarios de aplicacións e que non escala especialmente ben.

Enfoque #1: Blockchain como backend

Para aclarar as cousas, poñamos como exemplo a hostalería. Esta é unha industria enorme na que intermediarios como Booking.com, cobran unha taxa enorme para conectar hóspedes e hoteis.

En calquera situación na que queiramos derrotar a un intermediario deste tipo mediante este enfoque, tentaremos replicar a súa lóxica empresarial mediante contratos intelixentes nunha cadea de bloques como Ethereum.

Os contratos intelixentes de código aberto que se executan no "computador mundial" poden conectar os comerciantes aos consumidores sen un terceiro intermedio, reducindo finalmente as taxas e comisións que cobra o intermediario.

Como se mostra na imaxe de abaixo, os hoteis usan unha aplicación descentralizada para publicar na cadea de bloques información sobre cuartos, a súa dispoñibilidade e prezos en días laborables ou fins de semana, e quizais ata unha descrición das habitacións con toda a información relevante.

Calquera persoa que queira reservar unha habitación utiliza esta aplicación para buscar hoteis e cuartos aloxados na cadea de bloques. Unha vez que o usuario selecciona unha habitación, a reserva realízase enviando a cantidade necesaria de fichas ao hotel como depósito. E en resposta, o contrato intelixente actualiza a información da cadea de bloques de que o número xa non está dispoñible.

Hai dous lados do problema de escalabilidade con este enfoque. En primeiro lugar, o número máximo de transaccións por segundo. En segundo lugar, a cantidade de datos que se poden almacenar na cadea de bloques.

Imos facer uns cálculos aproximados. Booking.com di que ten case 2 millóns de hoteis rexistrados con eles. Digamos que o hotel medio ten 10 cuartos e cada un só se reserva 20 veces ao ano, o que dános unha media de 13 reservas por segundo.

Para poñer este número en perspectiva, vale a pena sinalar que Ethereum pode procesar aproximadamente 15 transaccións por segundo.

Ao mesmo tempo, paga a pena ter en conta que a nosa aplicación tamén conterá transaccións dos hoteis, para descargar e actualizar constantemente información sobre as súas habitacións. Os hoteis actualizan os prezos das habitacións con moita frecuencia, ás veces incluso a diario, e cada cambio de prezo ou descrición require unha transacción na cadea de bloques.

Tamén hai problemas de tamaño aquí: o peso da cadea de bloques de Ethereum superou recentemente a marca de 2TB. Se as aplicacións con este enfoque se fixeron realmente populares, a rede Ethereum volveríase extremadamente inestable.

Tal sistema baseado na cadea de bloques pode excluír aos estranxeiros debido á súa imparcialidade e falta de centralización, as principais vantaxes da tecnoloxía blockchain. Pero a cadea de bloques tamén ten outras características: distribúese e non se reescrita, estas son excelentes características, pero hai que pagalas na velocidade e na comisión das transaccións.

Polo tanto, os desenvolvedores de dapp deben avaliar coidadosamente se cada función que usa a cadea de bloques realmente necesita distribución e non escritura.

Por exemplo: cal é o beneficio de distribuír os datos de cada hotel en centos de máquinas de todo o mundo e almacenalos alí permanentemente? É realmente importante que os datos históricos sobre as tarifas e dispoñibilidade das habitacións estean sempre incluídos na cadea de bloques? Probablemente non.

Se comezamos a facer preguntas como estas, comezaremos a ver que non necesariamente necesitamos todas as funcións de cadea de bloques caras para todas as nosas funcións. Entón, cal é a alternativa?

Enfoque #2: Arquitectura inspirada en Blockstack

Aínda que a énfase principal Blockstack en aplicacións nas que os usuarios son os propietarios dos seus datos (por exemplo, como Texto aéreo, BentenSound, Optimizador de imaxe ou grafito), blockstack tamén ten a filosofía de usar a cadea de bloques lixeiramente, só cando sexa absolutamente necesario. O seu principal argumento é que a cadea de bloques é lenta e cara e, polo tanto, só debe usarse para transaccións únicas ou pouco frecuentes. O resto da interacción coas aplicacións debería producirse a través de peer-to-peer, é dicir. os usuarios de aplicacións descentralizadas deben compartir datos directamente entre si, en lugar de a través da cadea de bloques. Despois de todo, as aplicacións descentralizadas máis antigas e exitosas como BitTorrent, correo electrónico e Tor creáronse antes do propio concepto de blockchain.

Esquerda: o primeiro enfoque, no que os usuarios interactúan a través da cadea de bloques. Dereita: os usuarios interactúan directamente entre eles e a cadea de bloques só se usa para identificación e similares.

Volvamos ao exemplo de reserva de hoteis. Queremos un protocolo imparcial, independente e aberto para conectar os hóspedes cos hoteis. Noutras palabras, queremos eliminar o intermediario centralizado. Non necesitamos, por exemplo, gardar constantemente os prezos das habitacións nun libro común distribuído.

Por que non permitimos que os hóspedes e os hoteis interactúen directamente en lugar de a través da cadea de bloques. Os hoteis poden almacenar os seus prezos, a dispoñibilidade de cuartos e calquera outra información nalgún lugar onde todos poidan acceder, por exemplo, IPFS, Amazon S3 ou mesmo o seu propio servidor local. Isto é exactamente o que chamaba o sistema de almacenamento descentralizado de Blockstack Gaia. Permite aos usuarios escoller onde queren almacenar os seus datos e controlar quen pode acceder a eles mediante un enfoque chamado almacenamento multiusuario.

Para establecer a confianza, todos os datos do hotel están asinados criptográficamente polo propio hotel. Independentemente de onde se almacene estes datos, a súa integridade pódese verificar mediante as claves públicas asociadas á identidade dese hotel almacenadas na cadea de bloques.

No caso de Blockstack, só se almacena a súa información de identidade na cadea de bloques. A información sobre como obter os datos de cada usuario almacénase en ficheiros de zona e distribúese a través dunha rede peer-to-peer mediante nodos. E unha vez máis, non necesitas confiar nos datos que dan os nodos, porque podes verificar a súa autenticidade comparándoa cos hash que se almacenan na cadea de bloques e outros usuarios.

Nunha versión simplificada do sistema, os hóspedes usarán a rede peer-to-peer de Blockstack para buscar hoteis e obter información sobre as súas habitacións. E a autenticidade e integridade de todos os datos que recibe pódense verificar mediante chaves públicas e hash almacenados en circuíto virtual Blockstack.

Esta arquitectura é máis complexa que a primeira aproximación e require unha infraestrutura máis completa. De feito, aquí é exactamente onde entra Blockstack, que proporciona todos os compoñentes necesarios para crear un sistema tan descentralizado.

Con esta arquitectura, só almacenamos datos na cadea de bloques que realmente necesitan ser distribuídos e non sobrescritos. No caso de Blockstack, só necesitas transaccións na cadea de bloques para rexistrarte e indicar onde deben almacenarse os teus datos. É posible que teñas que facer máis transaccións se queres cambiar algunha desta información, pero este non é un evento recorrente.

Ademais, a lóxica da aplicación, en contraste co primeiro enfoque, execútase no lado do cliente e non en contratos intelixentes. Isto permite que o programador cambie esta lóxica sen actualizacións de contrato intelixente custosas ou, ás veces, incluso imposibles. E ao manter os datos e a lóxica das aplicacións fóra da cadea, as aplicacións descentralizadas poden acadar os niveis de rendemento e escalabilidade dos sistemas centralizados tradicionais.

Conclusión

As aplicacións que se executan en Blockstack poden escalar moito mellor que as aplicacións de cadea de bloques convencionais, pero é un enfoque máis novo cos seus propios problemas e preguntas sen resposta.

Por exemplo, se unha aplicación descentralizada non funciona con contratos intelixentes, isto reduce a necesidade de tokens de utilidade. Isto podería causar problemas ás empresas tendo en conta que as ICO foron a principal fonte de financiamento das aplicacións descentralizadas (incluíndo o propio Blockstack)

Aquí tamén hai problemas técnicos. Por exemplo, é relativamente fácil implementar unha función de reserva de hoteis nun contrato intelixente, onde nunha operación atómica, as reservas de habitacións realízanse a cambio de fichas. E non é moi obvio como funcionará a reserva nunha aplicación Blockstack sen contratos intelixentes.

As aplicacións destinadas a mercados globais con potencial para millóns de usuarios deben escalar moi ben para ter éxito. É un erro confiar unicamente nas cadeas de bloques para acadar este nivel de escalabilidade nun futuro próximo. Para poder competir con grandes actores do mercado centralizado como Booking.com, os desenvolvedores de aplicacións descentralizadas deberían considerar enfoques alternativos para deseñar as súas aplicacións, como o que ofrece Blockstack.

Fonte: www.habr.com