La guerra del OP_Return de 2014
La guerra del OP_Return de 2014 – Dapps Vs Transacciones de Bitcoin
En negrita aparecen datos que, personalmente, me han parecido relevantes.
Resumen:
En este artículo exploramos por qué las Dapps suelen construirse en Ethereum en lugar de Bitcoin, lo que nos lleva hasta marzo de 2014. Examinamos el debate sobre si un protocolo de Dapp llamado Counterparty debería utilizar la cadena de bloques de Bitcoin. A este a veces se le ha llamado "Las Guerras de OP_Return". Explicamos la historia del uso de OP_Return y las sidechains en Bitcoin. Concluimos argumentando que, guste o no, la cultura en la comunidad de desarrollo de Bitcoin de 2014 y la visión negativa de utilizar los datos de transacciones de Bitcoin para casos de uso alternativos jugaron un papel importante en impulsar a los desarrolladores de estas Dapps hacia sistemas alternativos como Ethereum, junto con otros factores.
Visión general:
A menudo nos han hecho la pregunta: ¿Por qué las Dapps, como los intercambios distribuidos, suelen estar en Ethereum en lugar de Bitcoin? Después de todo, ciertamente es posible construir Dapps, como intercambios distribuidos, sistemas de nombres o tokens alternativos en Bitcoin. Por supuesto, hay varias razones para esto, como:
i. El lenguaje de scripting nativo más flexible de Ethereum que facilita la construcción de Dapps,
ii. El tiempo de bloque más rápido de Ethereum, que hace que las Dapps sean más amigables para el usuario,
o iii. Bitcoin eligiendo una restricción de tamaño de bloque más conservadora que Ethereum, lo que podría resultar en tarifas potencialmente más altas en Bitcoin.
Todo lo anterior tuvo un impacto, sin embargo, en nuestra opinión, a menudo se exagera su impacto. El factor más significativo es la cultura. Algunos entusiastas y desarrolladores de Bitcoin simplemente no querían este tipo de actividad en la cadena de bloques de Bitcoin y lograron desalentarla con éxito. Esto parece haber ocurrido principalmente alrededor de marzo de 2014, y lo que sucedió en ese período es el tema de este artículo. Al mismo tiempo, los promotores de otras cadenas, como Ethereum, pueden haber aprovechado y exagerado esta aparente postura de los desarrolladores de Bitcoin para ayudar a que sus nuevas cadenas ganaran impulso.
El protocolo Counterparty
Como mencionamos en nuestro informe de septiembre de 2020, a principios de 2014 se lanzó Counterparty. Counterparty es una capa de protocolo sobre Bitcoin que permite funciones como la creación de nuevos tokens y el comercio de estos tokens en un intercambio distribuido. El sistema funciona utilizando partes de los datos de una transacción de Bitcoin y utilizando esto en el protocolo de Counterparty, como una función, como la creación de un token, el envío de un token o una oferta de mercado en un token en un intercambio distribuido.
Más concretamente, al principio Counterparty utilizaba el opcode de Bitcoin OP_CHECKMULTISIG para incluir datos relacionados con Counterparty en la cadena de bloques de Bitcoin. Este opcode debía usarse para verificar la firma de una transacción de hash de script pagadero (P2SH) con múltiples firmas. Un ejemplo de una transacción de Counterparty de julio de 2014 se puede ver aquí. La transacción envía Bitcoin de vuelta a la dirección de la que provino y también tiene tres salidas adicionales, donde los scripts de salida están relacionados con datos del protocolo de Counterparty. En este caso, fue la creación de un nuevo token llamado TICKET. El uso de OP_CHECKMULTISIG puede considerarse como un "hack", porque no era el uso previsto de este opcode. Ahora, Counterparty utiliza el opcode OP_Return de Bitcoin para almacenar datos, lo cual está más alineado con lo que los desarrolladores pretendían, hasta cierto punto. Por ejemplo, echa un vistazo a esta transacción más reciente de Counterparty, que utiliza OP_Return.
A principios de 2014 hubo una considerable experimentación, actividad de desarrollo, innovación y emoción en torno a Counterparty, que llevaba la delantera sobre una plataforma rival llamada Mastercoin.
¿Qué es OP_Return?
OP_Return es una salida de transacción en Bitcoin que es demostrablemente inutilizable. La función se puede utilizar para quemar Bitcoin o almacenar datos arbitrarios en la cadena de bloques de Bitcoin. Dado que los datos no forman parte del conjunto UTXO, almacenar datos de esta manera se dice que ayuda a escalar Bitcoin, ya que los nodos que participan en la poda no necesitan almacenar datos de OP_Return.
Las reglas de consenso de Bitcoin permiten un tamaño de OP_Return de hasta 10,000 bytes. Por ejemplo, en mayo de 2013, alguien se aprovechó de esta característica en la siguiente transacción. La salida de OP_Return en esta transacción contiene la letra de la canción "Never Gonna Give You Up" de 1987 de Rick Astley, la canción relacionada con el meme de Rickrolling.
Antes de 2014 las transacciones que contenían un OP_Return eran no estándar y no se retransmitían por los nodos Bitcoin comunes. Sin embargo, si un minero incluía esas transacciones, se consideraban válidas. En marzo de 2014, se lanzó Bitcoin Core 0.9.0 con la función OP_Return incluida como un tipo de transacción estándar, por lo tanto, las transacciones se empezaron a retransmitir por defecto. Las notas de lanzamiento en ese momento decían lo siguiente:
Esta modificación no respalda el almacenamiento de datos en la cadena de bloques. El cambio de OP_RETURN crea una salida demostrablemente podable, para evitar esquemas de almacenamiento de datos, algunos de los cuales ya estaban implementados, que almacenaban datos arbitrarios como imágenes en salidas de transacciones inutilizables para siempre, inflando la base de datos de UTXO de Bitcoin. Almacenar datos arbitrarios en la cadena de bloques sigue siendo una mala idea; es menos costoso y mucho más eficiente almacenar datos no relacionados con la moneda en otro lugar.
Bitcoin Core 0.9.0 solo retransmitiría transacciones con un OP_Return de 40 bytes o menos; si los datos eran más grandes, la transacción aún era válida pero no se retransmitía. Originalmente, se pretendía que el límite fuera de 80 bytes, pero después de mucha discusión, los desarrolladores se conformaron con 40 bytes. Para ser claro, el límite de retransmisión de OP_Return en una versión lanzada de Bitcoin Core nunca disminuyó.
En 2016, Bitcoin Core 0.11.1 finalmente aumentó el límite de retransmisión a 80 bytes, el límite que tenemos hoy en día. Esto significa que si alguien desea una transacción con una salida de OP_Return de más de 80 bytes hoy en día, debe minarla por sí mismo o enviarla directamente a un minero.
La guerra del OP_Return
El 20 de marzo de 2014, uno de los principales contribuyentes de Bitcoin en ese momento, Jeff Garzik, comenzó a publicar en el hilo de Counterparty del foro Bitcointalk. Jeff estaba criticando el uso del espacio en la cadena de bloques por parte de Counterparty.
Hasta la fecha, no he visto un esquema de volcado de datos en la cadena de bloques que no pueda ser reemplazado de manera segura con un simple hash. No es necesario almacenar datos en la cadena de bloques. Eso es pura pereza intelectual. El Timestamping hash(data) es igual de seguro, pero más eficiente. Además, una cadena secundaria puede estar probablemente vinculada a Bitcoin:
Jeff continuó diciendo:
CheckMultiSig está claramente destinado para claves públicas ECDSA, no para datos arbitrarios. No debería sorprender que usar una operación para algo diferente a su propósito previsto tenga consecuencias negativas, tal vez no intencionadas o desconocidas. Las transacciones de Counterparty no son "de acuerdo con el protocolo de Bitcoin", se cuelan porque nunca se esperó que la función se usara de esa manera.
Puede parecer extraño que Jeff tuviera esta opinión, dado que en 2017 parecía ser un defensor de bloques grandes, y que esta opinión sobre el uso conservador del espacio en bloque no parece conciliarse con la visión de bloques grandes. Sin embargo, esta aparente contradicción no apareció en absoluto en 2014. La opinión de Jeff en ese momento fue compartida en cierta medida por casi todos los desarrolladores activos del momento, incluidos aquellos que más tarde se convirtieron en defensores de bloques grandes. Según podemos decir, no hubo una conexión sencilla alguna entre la opinión sobre el límite de tamaño de bloque y este problema. Jeff era un desarrollador muy respetado en ese momento, y esta publicación fue motivo de considerable preocupación para los desarrolladores y usuarios de Counterparty.
Un desarrollador de Counterparty, con el seudónimo "BitcoinTangibleTrust", respondió a Jeff de la siguiente manera:
"Tienes toda la razón. No es necesario almacenar datos en la cadena de bloques. El sellado de tiempo de hash(data) es igual de seguro, mientras que es más eficiente. Una cadena secundaria puede estar provablemente vinculada a Bitcoin. Sin embargo, Counterparty ESTÁ almacenando datos en la cadena de bloques utilizando 256 bytes en cada transacción multi-sig de uno de tres, según la nota de PhantomPhreak [cofundador y desarrollador principal de Counterparty] que se muestra a continuación. Además, todas estas transacciones multi-sig son procesadas por los mineros."
El desarrollador continuó criticando el plan de los desarrolladores de Bitcoin de limitar OP_RETURN a solo 40 bytes en lugar de 80:
"Si OP_RETURN estaba destinado a detener/restringir el comportamiento multi-sig (Outputs no gastados) y, por ende, reducir el crecimiento de la cadena de bloques, entonces temo que al reducir el tamaño de OP_RETURN de 80 a 40 bytes, has hecho inadvertidamente que multi-sig sea MÁS ATRACTIVO para todos los metaprotocolos y has vuelto menos atractivo a OP_RETURN.
El principal desarrollador y cofundador de Counterparty, conocido como "PhantomPhreak", intervino:
"La idea es que almacenemos los datos en una segunda cadena de bloques y pongamos hashes de esos datos con marca de tiempo en Bitcoin, cuyos hashes también serían de menos de 40 bytes. La razón por la que no hicimos algo así no es cuestión de 'pereza intelectual', sino de complejidad de implementación. Counterparty no es un proyecto de ciencias de la computación; está diseñado para ser lo más simple posible, para obtener beneficios en velocidad de desarrollo. Incluso si tenemos que almacenar nuestros datos en salidas multi-sig en lugar de las salidas OP_RETURN demasiado pequeñas. Lo peor es definitivamente mejor en este espacio."
Al día siguiente, Jeff respondió:
"Se llama 'paseo gratis'. Dado que la abrumadora mayoría, más del 90%, de la aplicación para la cadena de bloques de Bitcoin es el uso de moneda, usar nodos completos como terminales de almacenamiento de datos tontos es simplemente abusar de un recurso de red completamente voluntario. La red replica datos de transacciones, ¿por qué no tomar un paseo gratis? En lugar de participar en la comunidad existente, Mastercoin y Counterparty simplemente encendieron un interruptor y comenzaron a usar nodos P2P de Bitcoin como almacenes de datos no deseados. Un Output no gastado nunca estuvo destinado a ser utilizado como almacenamiento arbitrario de datos. El hecho de que se pueda abusar de esa manera no lo hace correcto, ni remotamente eficiente, ni la mejor solución. La base de datos UTXO (Outputs no gastados o UTXO set) es la base de datos de acceso rápido de toda la red. Cada nodo necesita que esa base de datos sea lo más pequeña posible para el mejor procesamiento de las transacciones de la red. Codificar datos arbitrarios en outputs no gastados es un abuso a nivel de red, simple y llanamente. Toda la red soporta el costo."
Debido a la alta posición de Jeff dentro de la comunidad, la mayoría de las personas en la comunidad de Counterparty parecían ansiosas por participar y resolver el problema. Por ejemplo, BitcoinTangibleTrust respondió diciendo:
"Gracias por compartir tus pensamientos, Jeff. Entonces, ¿nos ayudarás a comenzar a interactuar con la comunidad existente de desarrolladores de Bitcoin Core? Es del interés de Counterparty actuar como un socio responsable, ya que necesitamos la cadena de bloques de Bitcoin si queremos sobrevivir. ¿Nos informarás cómo podemos empezar a trabajar juntos en estas preguntas?"
Otro desarrollador de Counterparty planteó otro punto:
"¿Existe alguna manera para que el protocolo de Bitcoin evite la forma en que XCP lo está utilizando, sin romper nada más?"
Si no hay forma de que los desarrolladores de Bitcoin bloqueen las transacciones relacionadas con Counterparty, tal vez esta oposición no importara y Counterparty podría seguir utilizando Bitcoin sin permiso.
Luke-Jr, desarrollador de Bitcoin y en ese momento operador de un grupo minero, intervino en el debate:
"Se supone que los mineros deben filtrar los abusos."
Luego, Luke-Jr sugirió que estos tipos de sistemas podrían construirse utilizando construcciones tipo merge mined sidechains, lo que podría evitar el crecimiento de la cadena de bloques.
"El problema no son las nuevas capas sino forzar cosas a las personas en contra de su voluntad. Las nuevas capas se pueden hacer de manera voluntaria, sin contaminar la cadena de bloques y obligar a los no participantes a almacenar los datos."
A Luke también se le preguntó por qué los desarrolladores de Bitcoin redujeron el tamaño de retransmisión previsto de OP_Return a 40 bytes en comparación con un límite de 80 bytes que se propuso originalmente. Luke respondió con los siguientes tres puntos:
Demasiadas personas tenían la impresión de que OP_RETURN era una característica destinada a ser utilizada. Nunca se pretendió como tal, solo como una forma de "dejar las ventanas abiertas para que no tengamos que reemplazar el vidrio cuando alguien entre". Es decir, para reducir el daño causado por personas que abusan de Bitcoin.
40 bytes son más que suficientes para todas las necesidades legítimas de vincular datos a una transacción: obtienes 32 bytes para un hash, más 8 bytes para algún tipo de identificador único (que realmente tampoco es necesario).
La propuesta original de 80 bytes estaba destinada a hashes de 512 bits, pero se determinó que esto era innecesario.
Luke-Jr continuó así:
"Esperemos que a medida que la minería vuelva a ser descentralizada, veremos menos tolerancia a las transacciones abusivas o de spam, ya sea la variante de OP_RETURN u otras. Ahora, si alguien tiene un caso de uso válido y necesario para almacenar realmente hashes con transacciones, obviamente, eso es algo que los mineros deberían considerar seriamente minar."
En ese momento, el grupo minero de Luke también comenzó a filtrar las transacciones relacionadas con Counterparty. En este punto, el miedo y la incertidumbre comenzaron a crecer en la comunidad de Counterparty. Necesitaban que OP_Return fuera de 80 bytes, o se verían obligados a seguir utilizando el opcode OP_CHECKMULTISIG. No parecía probable que aumentara a 80 bytes dadas las declaraciones de Luke. Además de esto, algunos temían que los desarrolladores incluso pudieran reducir aún más el límite, potencialmente expulsando a Counterparty de la red. Los desarrolladores de Bitcoin no parecían especialmente amigables con Counterparty y, por lo tanto, algunos podían sentir que sería difícil continuar utilizando el protocolo Bitcoin.
El 25 de marzo de 2014, Vitalik Buterin, el principal fundador de Ethereum, intervino, argumentando que el debate debería centrarse más en las tarifas y que si pagas tarifas suficientes, tu transacción debería incluirse legítimamente. Hoy en día, el algoritmo de tarifas de Ethereum es altamente complejo, con diferentes categorías de tarifas y tasas para muchos usos diferentes de la cadena de bloques, lo que resuelve en gran medida el problema de OP_Return. Se podría argumentar que SegWit en Bitcoin también mitiga el problema en cierta medida.
"Es culpa del protocolo que la batalla de OP_RETURN sea un problema tan grande. En un mundo ideal, el concepto de 'abuso' ni siquiera existiría; las tarifas serían obligatorias y cuidadosamente estructuradas para coincidir estrechamente con el costo real que impone una transacción dada a la red", dice. "Si puedes pagar las tarifas por lo que estás haciendo, deberías poder hacerlo sin hacer preguntas".
El 27 de marzo de 2014, Counterparty cambió la forma en que realizaba transacciones para evitar el filtro minero de Luke-Jr. Sin embargo, al día siguiente, Luke comentó lo siguiente:
"¡Excelentes noticias! Filtro agregado para bloquear esta basura en menos de 5 minutos y 1 línea de código."
Luke-Jr también comparó a Counterparty con una forma de abuso:
"Es abuso porque estás obligando a otros a descargar/almacenar tus datos en contra de su libre elección. Cada nodo completo debe descargar toda la cadena de bloques (podable o no). Cada nodo completo ha consentido en descargar y almacenar transacciones financieras. NO todos los nodos completos han consentido en almacenar cualquier otra cosa. Necesitas un consenso del 100% para esto, no simplemente algún subconjunto (es decir, no mineros; no desarrolladores) o incluso una mayoría. Además, todos son libres de almacenar datos que no estén en la cadena de bloques. No hay nada que ganar al ponerlo en la cadena de bloques, excepto que lo impones a aquellos que no lo desean. Expliquen cómo esto no es más que abuso..."
Cabreo con los desarrolladores de Bitcoin
Como era de esperar, la preocupación de los desarrolladores de Bitcoin eventualmente generó frustración y enojo por parte de algunos desarrolladores y usuarios de Counterparty. A continuación, incluimos algunos de sus comentarios. En primer lugar, el comentario de un usuario llamado "porqupine" en respuesta al bloqueo de las transacciones de Counterparty por parte del grupo minero de Luke-Jr:
"Genial, en lugar de que los desarrolladores se comprometan responsablemente a encontrar una solución, estás promoviendo un juego del gato y el ratón. ¿Te das cuenta de que también estás diciendo que al diablo con la neutralidad de la red? ¿Y tratando de poner en manos privadas qué tipo de transacciones deberían o no deberían realizar las personas en la cadena de bloques? ¿Qué sigue, sanciones para ciertos individuos que no te gusten? ¿Sanciones para transacciones transmitidas desde nodos en países cuyos gobiernos tengan una política exterior que no apruebes?"
El 21 de marzo de 2014, porqupine continuó diciendo:
> "Espera un minuto, ¿cuándo se decidió que cada nodo ha consentido almacenar datos del tipo X y no datos del tipo Y? Tal vez yo tampoco consintiera en almacenar transacciones de lavado de dinero, drogas ilícitas y armas, esclavitud humana, etc. Básicamente, estás negando la neutralidad del protocolo y decidiendo para qué debería y no debería usarse el protocolo. Y además de eso, no estás hablando en primera persona, sino que usas el pronombre 'nosotros', dando la impresión de que estás hablando en nombre de todos los mineros o usuarios del protocolo en su conjunto."
Otros expresaron su preocupación sobre por qué Jeff y Luke tenían el derecho de bloquear ciertos casos de uso sobre cualquier otra persona.
"No puedo creer esta actitud. No sabía que Bitcoin tenía propietarios. Pensé que yo y aproximadamente un millón de personas éramos los propietarios 🙂
PhantomPhreak, cofundador de Counterparty, dijo:
"En primer lugar, las transacciones de Counterparty son transacciones financieras. En segundo lugar, cada nodo completo ha consentido en descargar y almacenar la cadena de bloques de Bitcoin, nada menos. Es decir, transacciones que se ajustan al protocolo de Bitcoin, lo cual obviamente hacen las transacciones de Counterparty. Satoshi incrustó un mensaje político en el Bloque Génesis, por amor de Dios... Tienes una visión mucho más estrecha de los posibles casos de uso para Bitcoin que otros."
Él o ella continuó:
"Bitcoin hace muchas cosas para las que originalmente no estaba destinado. Sí, preferiríamos usar una solución más elegante que la que tenemos ahora. Counterparty fue diseñado originalmente para usar la salida OP_RETURN para almacenar todos sus datos de mensajes, lo que considero muy elegante y deja un impacto mínimo en la cadena de bloques. Planeamos todos nuestros formatos de mensajes en torno al límite de 80 bytes anunciado por Gavin en el blog oficial de Bitcoin. Solo usamos salidas multi-sig porque no tenemos otra opción. No queremos extender el protocolo Bitcoin. Queremos hacer algo completamente dentro de él, y de la manera más simple y directa posible, por los beneficios para la estabilidad, la seguridad, etc."
…
"Nuevamente, solo almacenamos transacciones financieras en la cadena de bloques, y estamos pagando por el espacio que estamos utilizando. Las transacciones financieras en salidas OP_RETURN no son más difíciles de almacenar para un nodo completo que cualquier otra cosa."
Otro usuario llamado "bitwhizz" dijo:
"Si no quieres almacenarlo, no lo hagas, bastante simple, no uses bitcoin, no descargues la cadena de bloques, estarás libre. Sin embargo, mi consentimiento significa que creo que Bitcoin tiene más funcionalidades que solo transacciones, y en base a ese hecho, nadie lo posee, y existe la función OP_RETURN. No veo por qué esa funcionalidad debería ser erradicada porque no quieres almacenar los datos, para los cuales ya tienes una elección libre."
"Anotheranonlol" dijo:
"Realmente no puedo entender cómo una transacción de Counterparty no constituiría una transacción financiera. Tampoco puedo entender el punto de vista de que, porque digamos que 1 nodo de 1000 no está dispuesto a aceptar estos datos, por defecto debería estar prohibido. Después de la reciente pesadilla que fue Mt. Gox y la gran cantidad de hacks, robos, cierres y pérdidas que surgieron al almacenar tu saldo en entidades centralizadas, parecía que Counterparty había encontrado una solución que permitía una solución descentralizada y sin confianza a este problema."
"Baddw" dijo:
"El hecho es que datos arbitrarios pueden ser almacenados en la cadena de bloques por cualquier persona en cualquier momento. Ya se ha estado utilizando con este propósito. Todo aquel que ejecute un nodo Bitcoin ya debería saber esto, y si no lo están, debería ser parte del aviso que aparece cuando instalan Bitcoin-QT (si lo hay; no recuerdo haber visto uno). Cualquier transacción de Bitcoin podría ser simplemente una transferencia de fondos, o podría ser una nota de amor, o podría ser un disparador para activar una bomba. Eliminar esta posibilidad mataría a Bitcoin, punto."
Y Baddw continuó diciendo:
"Muchos de los mayores desarrollos en la historia de la computación (y de hecho, en la historia tecnológica humana en su conjunto) son el resultado de personas que encuentran usos para cosas que no fueron previstas por sus inventores. Menos mal que la mayoría de los inventores no son tan protectores de sus inventos como para negarse a dejar que otros los utilicen para cosas nuevas. Aquellos que lo hicieron, se encontraron rápidamente superados."
Está claro a partir de estos comentarios que muchos usuarios y desarrolladores de Counterparty se sorprendieron y decepcionaron por la postura de los desarrolladores de Bitcoin. Aunque el proyecto continuó, al igual que Mastercoin, es probable que, para bien o para mal, algunos desarrolladores abandonaran Bitcoin como resultado de esto y en su lugar construyeran sus protocolos en otros sistemas de blockchain como Ethereum. En nuestra opinión, este momento de 2014 fue más significativo que cualquier otro. Sin embargo, otras personas pueden tener una opinión diferente.
Merge Mined Sidechains
A lo largo del debate sobre OP_Return, los opositores de Counterparty y la inflación de blockchain generalmente mencionaban alguna forma de sidechains minadas conjuntamente como una solución para las Dapps. De hecho, se dice que Satoshi favoreció este camino y que lo respaldó para un sistema de nombres de dominio en diciembre de 2010:
"Creo que sería posible que BitDNS sea una red completamente separada y una cadena de bloques separada, pero que comparta poder de CPU con Bitcoin. La única superposición sería hacer que los mineros puedan buscar pruebas de trabajo para ambas redes simultáneamente".
Hay muchas dificultades al implementar estos sistemas Dapp como sidechains, y nuestra comprensión de estas debilidades es mejor hoy que en 2014, cuando muchos asumían que podrían funcionar.
Complejidad: Una de las debilidades más significativas es la complejidad en la implementación y construcción de soluciones de sidechain. En la carrera por lanzar el protocolo rápidamente y ganar cuota de mercado, estos proyectos no tuvieron tiempo para construir una sidechain y el sistema de minería conjunta con Bitcoin.
Bitcoin como activo nativo: Puede que no sea posible tener Bitcoin no custodiado como un activo operativo en una sidechain, ya que puede no ser posible construir un "two-way peg" sin confianza. Esto es una gran debilidad para muchas Dapps que, por ejemplo, podrían querer usar Bitcoin como el par de negociación principal en un intercambio distribuido. Esta debilidad no parecía estar bien comprendida en 2014, ya que muchas personas simplemente asumían que podría funcionar de alguna manera.
Beneficios de escalabilidad limitados: Los beneficios de usar una sidechain pueden variar según el caso de uso. Por ejemplo, si se quiere construir un intercambio distribuido, cada oferta, oferta y coincidencia puede requerir todas las garantías de seguridad de la cadena principal. Con tanto uso de la cadena principal, para cada posible acción de cada usuario en el intercambio, los beneficios de escalabilidad del sistema de sidechain pueden ser extremadamente limitados.
En marzo de 2014, el desarrollador de Counterparty (xnova) expresó su oposición al concepto de sidechains de la siguiente manera.
Además, a menos que esté pasando por alto algo aquí, aún necesitaríamos analizar los datos de los bloques en esa segunda cadena de bloques (suponiendo que sea una implementación de Bitcoin o derivada de Bitcoin) para obtener nuestros datos almacenados. Por lo tanto:
* No habilitaría clientes tipo SPV para Counterparty en lo que Counterparty ofrece sobre la funcionalidad de Colored Coin (es decir, DEx, apuestas, devoluciones de activos, dividendos, CFD, etc.).
* Disminuiría la seguridad de las transacciones de Counterparty.
* Aumentaría considerablemente la complejidad de la implementación (aumentando la probabilidad de errores y vulnerabilidades).
El único beneficio dudoso sería la ligera reducción de nuestros requisitos de almacenamiento en la cadena de bloques (es decir, tal vez 20-40 bytes menos por transacción). Simplemente no veo cómo tendría sentido aquí. Un punto más: Counterparty puede aportar beneficios inmensos a Bitcoin, y esto se hará especialmente más evidente si/así Ethereum (y otras monedas similares no basadas en Bitcoin tipo "2.0") entran en escena. Mi sensación personal al menos es que Bitcoin podría necesitar ofertas en el ecosistema con este tipo de funcionalidad para competir eficazmente con Ethereum y (futuras) listas de características y atracciones del público, o correr el riesgo de volverse obsoleto, al menos entre inversores y operadores del mercado financiero, que ofrecen la capacidad de atraer miles de millones e incluso billones al ecosistema de Bitcoin a medida que gana más reconocimiento, confianza y participación mental con ellos.
Parece que algunas de las personas que argumentan a favor de las sidechains como una solución no estaban particularmente interesadas en muchas de las aplicaciones Dapp ni habían experimentado con ellas. Por lo tanto, nunca reflexionaron sobre las complejidades de construir un intercambio distribuido y cómo casi cada acción de cada usuario requiere seguridad. La mayoría de los desarrolladores de Bitcoin parecían bastante abiertos sobre lo que les interesa y claros sobre lo que quieren: dinero resistente a la censura, dinero no político, efectivo electrónico, etc., etc.
Conclusion
Después de 2014, la mayoría de los desarrolladores interesados en Dapps se enfocaron en construir sobre Ethereum u otros sistemas, no en Bitcoin. Ethereum luego logró una masa crítica de interés y momentum de desarrolladores, y el desarrollo de Dapps en Bitcoin fue mínimo. El punto clave de este artículo es enfatizar que el principal impulsor de esto no necesariamente fueron las tarifas o la máquina virtual de Ethereum y las capacidades técnicas más sólidas de Ethereum, sino simplemente que muchos entusiastas de Bitcoin y desarrolladores de Bitcoin no querían Dapps en Bitcoin y no estaban interesados en estas características. Para bien o para mal, algunos entusiastas de Bitcoin deliberadamente alejaron a muchos de estos desarrolladores de Dapps. Algunos entusiastas de Bitcoin creen que la mayoría de la actividad de Dapps está relacionada con estafas insostenibles o que esta actividad no es deseable en Bitcoin por razones de seguridad u otras. Al mismo tiempo, algunos promotores de monedas alternativas (por ejemplo, Ethereum) pueden haber exagerado el impacto y la importancia de las llamadas "OP_Return Wars" para impulsar sus cadenas emergentes.
Las opiniones de muchas personas han cambiado desde 2014. Bitcoin necesita tarifas de transacción para sobrevivir. En el ecosistema post 2016, en el que tenemos muchos bloques completos y tarifas algo más altas, se aprecia más ampliamente que cualquier transacción que pague tarifas es "legítima". Ciertos Dapps en Ethereum, como intercambios como Uniswap o protocolos de préstamos como AAVE y Compound, han demostrado ser exitosos e interesantes, hasta cierto punto. A pesar de esto, si a los entusiastas de Bitcoin les importa lo suficiente como para querer estos protocolos en Bitcoin, y si alguien realmente los construirá y usará, sigue siendo una pregunta abierta.
Powered by Mintter + The Hypermedia Protocol