馃嚜馃嚫 驴La blockchain tiene que ser una base de datos lenta y costosa? Cardano va a reescribir la historia

:es: Traducci贸n al espa帽ol de Must Blockchain be a slow and expensive Database? Cardano is going to rewrite History

Publicado por Cardanians en su blog de Medium, el 9 de Marzo de 2020.



El papel se usar谩 cada vez menos para dejar informaci贸n a las generaciones futuras. Las bases de datos pueden servirnos mejor. La informaci贸n de los activos estar谩 en la blockchain.

Durante mucho tiempo se ha dicho que la blockchain es una base de datos lenta, cara e ineficaz, y que no puede ser utilizada para nada m谩s que para las criptomonedas. En el art铆culo explicaremos por qu茅 una base de datos no puede ser una blockchain, y por qu茅 la blockchain puede no ser necesariamente lenta o cara, a menos que se pretenda que lo sea. El consenso de la red PoS puede cambiar esa l贸gica, y Cardano construye uno.

La base de datos no es una blockchain

Empecemos por refutar un mito. La base de datos nunca ser谩 una blockchain. Para mantenerlo simple, una base de datos es un espacio para almacenar cosas. Tu empleador probablemente tiene una base de datos y almacena informaci贸n digital sobre ti. Cada tienda electr贸nica tiene una base de datos que guarda informaci贸n sobre todos los bienes, pedidos, clientes, etc. Blockchain es un ledger, un libro contable. Puedes imaginarte al ledger como un balance o un libro de cuentas. Es una colecci贸n de cosas del mismo tipo y donde hay informaci贸n sobre la propiedad. El ledger digital es capaz de llevar un registro de la historia y es posible obtener el 煤ltimo estado v谩lido. Como usuario de un monedero de criptomonedas, el libro de cuentas puede proporcionar informaci贸n sobre cu谩ntas monedas poseen Alice o Bob.

2
Base de datos. No hay consenso en la red y el administrador tiene un control absoluto sobre ella. Los datos no son propiedad del usuario.

Es posible crear, leer, actualizar y borrar (operaciones CRUD) datos de una base de datos, y todas las operaciones son r谩pidas y altamente escalables. Esto es posible porque s贸lo hay un nodo o servidor con la base de datos y no se requiere un consenso de red. Por lo tanto, todas las operaciones se realizan inmediatamente. Blockchain es inmutable, por lo que s贸lo es posible a帽adir nuevos datos sin la posibilidad de reescribir el historial. Por lo tanto, la historia es siempre completamente auditable. La blockchain es capaz de mantener todas las transacciones. Por lo tanto, es posible recorrer todas las transacciones hist贸ricas almacenadas desde el primer bloque de la cadena hasta el final. Una vez que se lee el 煤ltimo bloque a帽adido se puede ver el estado actual del ledger.

Lee m谩s sobre las diferencias entre la base de datos y la blockchain en este art铆culo.

Una vez que se permite cambiar los datos en la base de datos y los datos cumplen las condiciones, el registro se cambia de inmediato. Normalmente s贸lo hay una copia de la base de datos, pero se puede hacer una copia de seguridad regularmente para evitar p茅rdidas de datos inesperadas. Un administrador tiene el control total sobre la base de datos, de modo que los datos pueden ser cambiados en cualquier momento por todo aquel que tenga los privilegios necesarios. Una base de datos, como 煤nico punto de fallo, puede incluso ser hackeada y los datos pueden ser cambiados por un atacante.

Por su parte, para a帽adir nuevos datos en una blockchain, normalmente a帽adiendo un nuevo bloque, se requiere un consenso en la red distribuida. Los nodos validan un nuevo bloque propuesto junto con las transacciones y se a帽adir谩 permanentemente a la blockchain s贸lo si la mayor铆a de los nodos est谩n de acuerdo. Despu茅s del acuerdo, todos los nodos honestos tendr谩n la misma copia del ledger. As铆 que no hay una autoridad central con derecho a cambiar el ledger. Hay un grupo de operadores independientes, propietarios de nodos validadores que participan activamente en el consenso, y el poder de decisi贸n se distribuye entre todos ellos.

3
Base de datos vs. blockchain.

Las principales diferencias entre la base de datos y una blockchain radican en que hay reglas espec铆ficas sobre c贸mo validar las transacciones y a帽adir un nuevo bloque a una blockchain. Adem谩s, la validaci贸n se ejecuta en todos los nodos completos de una red distribuida. Los nodos honestos mantienen el estado v谩lido del ledger. Los datos s贸lo se a帽aden y la historia es inmutable.

Los datos en s铆, por ejemplo, la posesi贸n de monedas ADA, est谩 como bloqueada para un propietario. En otras palabras, los datos poseen propiedad, y 煤nicamente el due帽o de una llave privada puede cambiar la propiedad. Para gastar las monedas ADA de una direcci贸n, s贸lo el propietario de la llave privada correspondiente puede firmar una transacci贸n. La transacci贸n es validada por todos los nodos validadores, y si es correcta (y todo el bloque tambi茅n lo es) entonces se cambia la propiedad de las monedas.

La blockchain es poderosa cuando se necesita almacenar inmutablemente la informaci贸n que para un usuario X un estado Y es v谩lido en el momento Z. Es muy adecuada para mantener la informaci贸n de propiedad de cosas valiosas. Por ejemplo, las monedas ADA, como hemos mostrado anteriormente. La belleza de la blockchain es que el propietario realmente posee activos e incluso la red no es capaz de cambiar eso sin la llave privada. S贸lo el propietario puede iniciar el cambio de propiedad a trav茅s de una transacci贸n, y la red s贸lo valida la solicitud y puede aceptarla a帽adiendo la transacci贸n en un nuevo bloque que se a帽ade a la blockchain. El cambio de propiedad se produce plenamente de manera descentralizada. Es algo que no se puede lograr con una base de datos. Dentro de la base de datos, siempre hay una autoridad central en la que hay que confiar.

4
El usuario X firm贸 una transacci贸n para cambiar el estado Y en el momento en que Z. La blockchain valida la transacci贸n y debe llegar a un consenso de la red para aceptar el cambio propuesto. El usuario X realmente posee un activo y puede cambiar el estado Y. Nadie m谩s puede hacerlo.

LabBlockchain s贸lo mantiene inmutablemente la informaci贸n sobre los datos, y puede ser p煤blica y auditable. Es f谩cil para la red guardar un n煤mero m谩ximo de monedas o tokens ya que todos los datos se almacenan en el ledger. Cada nodo completo es consciente del estado actual y puede validar f谩cilmente la correcci贸n de los cambios propuestos. Como dijimos, nadie es capaz de cambiar los datos en el ledger, por ejemplo, la propiedad de las monedas ADA, excepto el propietario. Por lo tanto, la red distribuida es la parte de confianza entre Alice y Bob cuando quieren interactuar entre ellos. La red distribuida no requiere de confianza b谩sicamente por dos razones: La red en s铆 no puede cambiar ning煤n dato, ya que siempre se requiere del consenso distribuido involucrado y de la firma del propietario. En otras palabras, si eres due帽o de monedas ADA, s贸lo t煤 eres responsable de mantener las llaves privadas que te permiten gastar las monedas, y nadie m谩s puede hacerlo. La red s贸lo valida las voluntades y act煤a.

El estado Y, que el usuario X puede cambiar, puede ser m谩s que s贸lo la propiedad de las monedas ADA. Puede ser cualquier otro token fungible o no fungible emitido. Por lo tanto, la blockchain es capaz de mantener la informaci贸n sobre acciones, bonos, propiedad, art铆culos de juego, etc. El estado Y puede ser incluso una condici贸n definida en un contrato inteligente que diga que si Alice env铆a un token Q a Bob, entonces Alice se convierte en la propietaria de un token R.

Lea m谩s sobre los contratos inteligentes en este art铆culo.

La blockchain es muy 煤til para mantener casi cualquier tipo de informaci贸n de propiedad si es posible digitalizarla. Sin embargo, esta caracter铆stica por s铆 sola no es suficiente y necesitamos trabajar en otras caracter铆sticas 煤tiles ya que s贸lo una combinaci贸n de m煤ltiples caracter铆sticas har谩 que las redes distribuidas modernas como Cardano sean a煤n m谩s poderosas. Para poder hacer uso a煤n m谩s de las redes distribuidas, necesitamos que escalen. Esto significa que muchos usuarios puedan usarlas al mismo tiempo. Hasta ahora ha sido un problema, y por lo tanto la narrativa apareci贸 diciendo que la blockchain es una base de datos lenta y costosa. Si vamos a hablar de las criptomonedas, algo que la gente quiere usar a diario, las redes deben necesariamente escalar. Si las transacciones han de ser lentas y costosas, no podemos ni siquiera hablar de criptomonedas utilizables globalmente. La escalabilidad, pero tambi茅n la programabilidad del dinero y los tokens, los v铆nculos m谩s estrechos con el mundo f铆sico, y el trabajo con la identidad digital abrir谩n puertas que ni siquiera conocemos hoy en d铆a.

Veamos las razones por las que se dice que la blockchain es lenta y costosa.

驴Por qu茅 la blockchain tiende a ser lenta y cara?

La raz贸n por la que la blockchain tiende a ser lenta es muy simple y directa. El consenso de la red distribuida siempre necesitar谩 m谩s tiempo que una base de datos. La base de datos s贸lo valida r谩pidamente una solicitud y hace los cambios necesarios de inmediato. La escalabilidad no es un problema. Una red distribuida necesita m谩s tiempo, ya que un nodo suele reunir unas pocas transacciones para crear un nuevo bloque. El bloque es validado luego por otros nodos. Cada consenso funciona de manera algo diferente. Algunos pueden depender de una potente comunicaci贸n interna, otros pueden ser capaces de conceder derechos de creaci贸n de bloques a un nodo en particular y luego verificar que todo est茅 bien.

La prueba de trabajo (PoW) es el primer consenso de red exitoso usado en el mundo de las criptomonedas, con un tiempo de bloque establecido en ~10 minutos. La prueba de trabajo es muy simple. Todos los nodos interesados en recibir una recompensa por el bloque intentan ganar en una competencia espec铆fica. Todos los nodos tratan de resolver una tarea dif铆cil que toma aproximadamente 10 minutos. La tarea es muy exigente en cuanto a potencia de computaci贸n y es dif铆cil predecir si la tarea toma 2, 10 o 60 minutos. S贸lo un nodo ganar谩 la competencia. Una vez que un nodo ha resuelto la tarea, s贸lo propaga el bloque a otros nodos para su validaci贸n. Una parte del proceso de validaci贸n del bloque es tambi茅n la verificaci贸n de que la tarea ha sido realmente resuelta para que el bloque pueda ser a帽adido a la blockchain.

PoW es muy caro e ineficaz. La potencia de c谩lculo necesaria para resolver la tarea requiere mucha energ铆a el茅ctrica. Para mantener una buena competencia en el consenso PoW, el bloque tiene que tener un tama帽o limitado, y en el tama帽o limitado s贸lo se puede insertar una cantidad limitada de transacciones.

Si consideramos que una transacci贸n t铆pica podr铆a tener ~250B, entonces el bloque de 1MB podr铆a contener 4000 transacciones. 4000 transacciones por 10 minutos nos da una tasa de 6,7 transacciones por segundo. El PoW de Bitcoin es actualmente capaz de procesar no m谩s de 10 transacciones por segundo (TPS) y la raz贸n es principalmente el largo tiempo por bloque (el tiempo necesario para producir un bloque).

5
Blockchain. Se requiere de un consenso en la red para cambiar los saldos. No hay una autoridad central.

PoW originalmente fue anti-spam o protegido contra DoS que se introdujo en 1993. Un solicitante del servicio ten铆a que proporcionar PoW, un trabajo dif铆cil y costoso antes de que el servicio fuera proporcionado. Por lo tanto, un atacante no pod铆a hacer spam en la red ya que una generaci贸n de una mayor cantidad de mensajes requerir铆a una gran cantidad de PoW, por lo que ser铆a costoso. El PoW no fue inventado para ser un consenso de la red. Satoshi Nakamoto lo us贸 ya que en ese momento era dif铆cil encontrar otro consenso distribuido confiable adecuado para una red global. El PoW es lento, ineficaz y caro. A pesar de todas las desventajas, funciona y es muy seguro. El PoW es simple y robusto, y es muy caro para producir un bloque fraudulento. Un atacante potencial en la red PoW tendr铆a que tener una tasa de hash muy alta para solventar el ataque. La seguridad se considera la mayor ventaja del PoW. Sin embargo, el PoW tiende a estar centralizado.

Podr铆amos considerar dos formas de aumentar el rendimiento, es decir, para procesar m谩s transacciones por segundo. Podr铆amos aumentar el tama帽o del bloque para poder insertar m谩s transacciones en 茅l, o podr铆amos disminuir el tiempo por bloque para producir bloques m谩s a menudo. La latencia de la red hace casi imposible aumentar el tama帽o de los bloques. Si el bloque fuera demasiado grande, la propagaci贸n a todos los nodos llevar铆a mucho tiempo. Ver abajo el tiempo necesario para entregar un bloque de 2Mb desde Londres a otras partes del mundo a trav茅s de TCP/IP:

  • Paris 鈥 0.1s
  • US East coast 鈥 1.1s
  • US West coast 鈥 2.5s
  • Brazil 鈥 3.0s
  • Korea 鈥 3.4s
  • Australia 鈥 5.3s

El aumento del tama帽o del bloque no estar谩 sobre la mesa durante alg煤n tiempo, pero en el futuro, probablemente ser谩 posible aumentarlo. As铆 que tenemos que reducir el tiempo por bloque. Sin embargo, esto s贸lo es posible si utilizamos otro consenso de red, y no comprometemos la seguridad y la descentralizaci贸n.

El PoS puede ser un consenso r谩pido y barato

Se espera que el consenso del protocolo PoS de Cardano, Ouroboros, pueda llegar a procesar entre 200 y 250 transacciones por segundo. Otros par谩metros del consenso podr铆an ser el tiempo por bloque en alrededor de 20 segundos, tener el 50% de las monedas delegadas necesarias para cometer el ataque del 51% y aproximadamente 1000 pools en la red.

Ouroboros elevar谩 fundamentalmente la calidad de la descentralizaci贸n en las redes p煤blicas. La situaci贸n actual no es muy buena si se considera que s贸lo hay ~10 pools significativos en la red de Bitcoin. Otros proyectos importantes utilizan el DPoS, que tiene un n煤mero fijo de entidades con derecho a crear un bloque. Por ejemplo, EOS tiene 21 entidades de este tipo y Tron s贸lo 26. Ethereum 1.0 usa PoW, y en cuanto al n煤mero de grandes jugadores es muy similar a Bitcoin. Ethereum 2.0 migrar谩 a PoS para lograr una mejor descentralizaci贸n y escalabilidad tambi茅n.

Si no est谩s seguro de cu谩l es exactamente la escalabilidad y por qu茅 es tan necesaria, entonces lee nuestro art铆culo sobre este tema.

La calidad de la descentralizaci贸n es la caracter铆stica m谩s importante de las redes distribuidas. A veces podemos escuchar que no es el grado de descentralizaci贸n, sino el grado de seguridad. Bueno, hoy en d铆a tenemos una red bastante segura y centralizada. La verdad es que necesitamos tanto de la descentralizaci贸n como de la seguridad. Una sin la otra no puede funcionar bien a largo plazo. Sin embargo, si tuvi茅ramos que preferir una caracter铆stica, tendr铆a que ser la descentralizaci贸n. Cardano pondr谩 el list贸n muy alto en cuanto al nivel de descentralizaci贸n. S贸lo har谩 falta demostrar la calidad de la seguridad. El equipo de IOHK ha investigado durante mucho tiempo el consenso PoW, y ha descubierto c贸mo ofrecer un consenso PoS igualmente seguro. Esto se ha logrado gracias a una larga y detallada investigaci贸n. Ahora es necesario demostrarlo a todo el mundo.

Procesar 250 transacciones por segundo no es suficiente para un protocolo global que tiene ambiciones de ser usado para el pago e incluso para m谩s cosas. Cardano tiene un as bajo la manga. Ouroboros Hydra incorporar谩 el sharding (fragmentaci贸n). El sharding es una forma de procesar transacciones en paralelo a trav茅s de m煤ltiples redes pero manteniendo un 煤nico estado consistente.

El 鈥渟harding鈥 se basa en el supuesto de que todos los nodos de la red no tienen por qu茅 validar todas las transacciones. Los nodos pueden dividirse en m煤ltiples subredes, unidades o fragmentos. Cada fragmento validar谩 entonces s贸lo una parte de todas las transacciones. Si la red tuviera 1000 nodos que participaran activamente en el consenso de la red y se dividieran en 10 fragmentos, la red podr铆a validar aproximadamente 10 veces m谩s transacciones. Tambi茅n es probable que se pueda aumentar el n煤mero de nodos en los fragmentos. Gracias al sharding podremos multiplicar las TPS de una blockchain por varias decenas, tal vez cientos. Podr铆a ser posible llegar a las necesarias decenas de miles de transacciones por segundo. Por ejemplo, si Cardano tuviera 10 fragmentos, entonces el rendimiento ser铆a de 2.500 TPS.

6
Sharding: 4 fragmentos, 1 estado

Mantener la red consistente y uniforme a trav茅s de todos los fragmentos es exigente para la sincronizaci贸n entre los fragmentos, y la latencia de la red sigue siendo un gran enemigo. Lograr el paralelismo en un entorno de red distribuida es uno de los mayores desaf铆os para el equipo de IOHK.

Con el sharding, Cardano puede ser descentralizado, seguro y escalable en su primera capa. Es muy importante desde el punto de vista de la experiencia del usuario y la fiabilidad general. Veamos algunas otras alternativas sobre c贸mo lograr una mayor escalabilidad.

Arquitectura de capas

B谩sicamente, cada proyecto tiene dos opciones b谩sicas para mejorar el problema actual m谩s apremiante de la blockchain, la escalabilidad. El equipo puede mejorar el consenso de la red en la primera capa, o usar otra capa con diferentes propiedades. Un ejemplo de la primera opci贸n es trabajar en con el PoS y el sharding. Un ejemplo de la segunda opci贸n es construir una segunda capa como la Lightning Network (LN). Este enfoque se llama arquitectura en capas.

Bitcoin, como representante de la primera generaci贸n de blockchain, eligi贸 la segunda opci贸n. Las monedas pasan de la primera capa a la segunda, donde se pueden utilizar transacciones r谩pidas y baratas con un rendimiento de red mucho mayor. Lightning Network es una red completamente diferente y separada con sus propios nodos, direcciones, billeteras, etc. La transferencia de monedas desde y hacia la segunda capa requiere de transacciones en la primera capa de la cadena.

7
Arquitectura de capas.

Sin embargo, esta soluci贸n tambi茅n tiene algunas desventajas. Una vez que la moneda aparece en la segunda capa, la seguridad de sus monedas depende totalmente de esa capa. LN no tiene un consenso de red donde los nodos traten de ponerse de acuerdo en una versi贸n de la verdad. En lugar de esto, se hace un esfuerzo para asegurar que la transferencia de monedas entre capas sea suficientemente segura y que las monedas no puedan ser creadas de la nada o se pierdan dentro del canal de pago establecido, por ejemplo entre Alice y Bob. La seguridad ser谩 supervisada por entidades centralizadas llamadas Vigilantes (hasta donde yo s茅 no hay ning煤n mecanismo de incentivo).

Ahora imagina la situaci贸n cuando Alice ha abierto el canal de pago A con Bob para poder enviar las monedas r谩pidamente en Lightning Network y Bob ha abierto otro canal de pago B con Carol. Mira la foto de abajo.

8

Las perlas amarillas representan monedas. Cualquier participante puede enviar 3 monedas a la contraparte a trav茅s del canal. Nota que no hay un canal directo creado entre Alice y Carol. Si Alice quisiera enviar 3 monedas a Carol, entonces se podr铆a crear un nuevo canal a trav茅s de una lenta y costosa transacci贸n en la primera capa de la cadena. La segunda opci贸n es utilizar los dos canales de pago ya abiertos, A y B. En este caso, las monedas de Bob deben utilizarse para transferir el valor de Alice a Carol. Al final, Alice tendr谩 0 monedas, Bob tendr谩 6 monedas en el canal A que est谩 abierto entre ellos, y Carol tendr谩 6 monedas. Bob tendr谩 0 monedas en el canal B que est谩 abierto entre Bob y Carol. Bob tiene 6 monedas antes y despu茅s de la transacci贸n entre Alice y Carol. Sin embargo, su liquidez en el canal B es ahora 0.

B谩sicamente significa que Bob ya no puede enviar monedas a Carol y Alice no puede enviar ninguna moneda a Bob. Por lo tanto, si Alice quisiera enviar monedas a Bob, el canal A tendr铆a que cerrarse y volver a abrirse mediante transacciones en la primera capa. Lo mismo se necesita si Bob quisiera enviar monedas a Carol. A帽adido a que todas las billeteras deben estar en l铆nea para que la transacci贸n entre Alice y Carol se lleve a cabo.

Para poder enviar monedas a trav茅s de m煤ltiples canales, debe haber una entidad en la red que sea capaz de monitorear constantemente el estado actual de todos los canales y buscar una ruta que pueda ser usada para el pago. Con el aumento del n煤mero de usuarios y del n煤mero de canales, esto puede convertirse en una tarea cada vez m谩s dif铆cil desde el punto de vista inform谩tico y el proceso probablemente conducir谩 a la centralizaci贸n. Para poder enviar monedas a trav茅s de m煤ltiples canales, 茅stos deben tener suficiente liquidez. Una vez agotada la liquidez, es necesario cerrar y reabrir los canales. LN est谩 destinado 煤nicamente a las microtransacciones. Siempre puede ser dif铆cil enviar cantidades m谩s grandes y es probable que algunos fallos de pago sean inevitables.

PoS vs. segundas capas

Las segundas capas son definitivamente importantes y ser谩n necesarias. Por otro lado, LN no es necesariamente una soluci贸n completa y suficiente para el problema de la escalabilidad. Imagina que existan m煤ltiples segundas capas, y esas segundas capas tambi茅n intercambien monedas entre s铆. Bajo esta situaci贸n, ser铆a muy dif铆cil confiar en cu谩ntas monedas o tokens podr铆an existir. Cuantas m谩s redes de segunda capa existan, m谩s dif铆cil ser谩 sincronizar los datos sobre el n煤mero de monedas en circulaci贸n.

Tener la escalabilidad resuelta dentro de la primera capa a trav茅s del PoS de Ouroboros es probablemente una soluci贸n m谩s fiable y segura. La segunda capa y las capas adicionales tambi茅n son necesarias en un sistema en el que se utilizar谩 el sistema PoS. Sin embargo, la cuesti贸n radica siempre en c贸mo garantizar una buena seguridad en las capas superiores, y con qu茅 frecuencia y por cu谩nto tiempo ser谩 posible realizar el asentamiento en la primera capa. Necesitamos urgentemente escalar en la primera capa, ya que esta capa siempre ser谩 la m谩s segura. Mantener las monedas en las capas superiores por mucho tiempo no ser谩 confiable, y si muchos asentamientos en la primera capa se hacen con frecuencia, la primera capa todav铆a puede atascarse y las comisiones seguir谩n siendo altas.

Mucha gente argumenta que el PoS nunca ser谩 tan seguro como el PoW. IOHK ha demostrado matem谩ticamente que es posible utilizar la criptograf铆a moderna. Tal vez necesitemos el PoW y tal vez tambi茅n el PoS. La adopci贸n de redes distribuidas abiertas es todav铆a muy baja y uno de los obst谩culos m谩s debatidos es el problema de la escalabilidad. Tenemos una soluci贸n. Son la segunda capa y el PoS con el sharding. Ahora s贸lo necesitamos tiempo para probar ambas soluciones y hacer que la gente elija.

La segunda capa como Lightning Network probablemente siempre requerir谩 la apertura y cierre de los canales y cuidarlos en un sentido de liquidez. El usuario tiene que considerar con qui茅n abre qu茅 canal, y cu谩nto dinero se necesita para ponerlo. Si las transacciones en la primera capa son costosas, ser谩 costoso mantener los canales en la segunda capa. No tienes que lidiar con esto dentro del consenso PoS. Tendr谩s todos tus activos en una billetera, y podr谩s enviar una transacci贸n directa a cualquiera en cualquier momento. Todo sucede en la blockchain. No hay dependencia a las billeteras en l铆nea, a la liquidez, a los nodos buscando rutas, y los usuarios no necesitar谩n depender de redes fuera de la blockchain y el consenso de la red. Al menos desde el punto de vista de la interfaz de usuario, el PoS puede ofrecer una soluci贸n mucho m谩s agradable.

Resumen

La blockchain puede asegurar la propiedad de tus bienes. Es una gran caracter铆stica que la base de datos no puede ofrecer. Para que esta caracter铆stica sea adoptada universalmente, necesita estar disponible t茅cnicamente. No podemos hacerlo ahora mismo, pero podremos hacerlo pronto. Si la gente decide hacer un uso mayor de la blockchain y de sus posibilidades, entonces el cielo es el l铆mite.

Los defensores del consenso PoW argumentan que el sistema PoS no funcionar谩. Es necesario darse cuenta de que el PoW funciona bien a pesar de que probablemente fue implementado por una sola persona durante un a帽o. Un gran equipo de profesionales ha estado trabajando en el protocolo de Cardano durante m谩s de 5 a帽os. No hay ninguna raz贸n l贸gica para pensar que no puedan tener 茅xito. No tiene sentido decir que porque tenemos PoW, no necesitemos PoS. El mercado es a煤n muy joven y la gente a煤n no ha elegido lo que quiere usar. Siempre es mejor elegir entre m谩s alternativas que verse obligado a usar una 煤nica soluci贸n.


Considera la posibilidad de delegar tus ADA en Cardanians, ticker CRDNS.

Nuestro equipo est谩 relacionado con el desarrollo de Adapools.org.

Si te gustan nuestros art铆culos, puedes apoyarnos con una donaci贸n:

[ADA] DdzFFzCqrhsp2Qsit7VGq5jpjehGFmVt9rvJzSRnWJ8S5HaMqpXxg7kguevE7jvxhPgmHbrKGtRXGGF7jVHjcnSBfQ5sEGKB7HVvDNyR

[BTC] 3GvKDw7GWfyawMo3QcHkVJCUjGvbyUqboA

Embajadores de Cardano: Jaromir Tesar y Lukas Barta

V铆as de contacto

Web: https://cardanians.io
Twitter: @Cardanians_io
Adapool Twitter: @AdapoolsO
Email: hello@cardanians.io
Telegram: Telegram: Contact @cardanians
Facebook: Cardano CZ/SK: Cardano [ADA] CZ/SK

2 Likes