Recientemente, hubo una pequeña disputa entre las facciones Core e Unlimited de la comunidad Bitcoin, una disputa que representa quizás la quincuagésima vez que se debatió el mismo tema, pero que, no obstante, es interesante porque resalta un punto filosófico muy sutil sobre cómo funcionan las cadenas de bloques. trabajar.
ViaBTC, un pool de minería que favorece a Unlimited, tuiteó "El poder de hash es ley", un tema de conversación habitual para el lado ilimitado, que cree que los mineros tienen, y deberían tener, un papel muy importante en la gobernanza de Bitcoin, siendo el argumento habitual que los mineros son la única categoría de usuarios que tiene un incentivo financiero grande e ilíquido en el éxito de Bitcoin. Greg Maxwell (desde el lado del Núcleo) respondió que "la seguridad de Bitcoin funciona precisamente porque el poder hash NO es ley".
El argumento central es que los mineros solo tienen un papel limitado en el sistema Bitcoin, para asegurar el orden de las transacciones, y NO deberían tener el poder de determinar nada más, incluidos los límites de tamaño de bloque y otras reglas de validez de bloque. Estas restricciones son impuestas por nodos completos administrados por los usuarios: si los mineros comienzan a producir bloques de acuerdo con un conjunto de reglas diferentes a las reglas que aplican los nodos de los usuarios, entonces los nodos de los usuarios simplemente rechazarán los bloques, independientemente de si son el 10% o el 60%. El % o el 99% del hashpower está detrás de ellos. A esto, Unlimited a menudo responde con algo como "si el 90% del poder de hash está detrás de una nueva cadena que aumenta el límite de bloques, y la cadena antigua con un 10% de poder de hash ahora es diez veces más lenta durante cinco meses hasta que la dificultad se reajusta, ¿lo harías?". realmente ¿No actualiza a su cliente para que acepte la nueva cadena?
Muchas personas a menudo argumentar en contra el uso de cadenas de bloques públicas para aplicaciones que involucran activos del mundo real o cualquier cosa con riesgo de contraparte. Las críticas son totales, diciendo que no tiene sentido implementar tales casos de uso en cadenas de bloques públicas, o parciales, diciendo que si bien puede haber ventajas al almacenar el datos en una cadena pública, el lógica de negocios debe ejecutarse fuera de la cadena.
El argumento que se suele utilizar es que en este tipo de aplicaciones ya existen puntos de confianza: hay alguien que posee los activos físicos que respaldan los activos autorizados en la cadena, y que alguien siempre puede optar por quedarse con los activos o verse obligado a congelarlos. un gobierno o un banco, por lo que gestionar las representaciones digitales de estos activos en una cadena de bloques es como pagar por una puerta de acero reforzada para la casa cuando la ventana está abierta. En cambio, dichos sistemas deberían utilizar cadenas privadas, o incluso soluciones tradicionales basadas en servidores, tal vez agregando fragmentos de criptografía para mejorar la auditabilidad y, de ese modo, ahorrar en las ineficiencias y los costos de poner todo en una cadena de bloques.
Los argumentos anteriores son defectuosos en sus formas puras, y lo son de manera similar. mientras es teóricamente posible para que los mineros cambien el 99% de su poder de hash a una cadena con nuevas reglas (para dar un ejemplo en el que esto es indiscutiblemente malo, supongamos que están aumentando la recompensa del bloque), e incluso campamento de generación la antigua cadena para hacerla permanentemente inútil, y también es teóricamente posible que un administrador centralizado de una moneda respaldada por activos deje de respetar un token digital y cree un nuevo token digital con los mismos saldos que el antiguo token, excepto con una cuenta en particular. saldo reducido a cero y comenzar a honrar el nuevo token, en la práctica Esas cosas son bastante difíciles de hacer..
En el primer caso, los usuarios tendrán que darse cuenta de que algo anda mal con la cadena existente, aceptar que deben ir a la nueva cadena en la que los mineros están minando ahora y descargar el software que acepte las nuevas reglas. En el segundo caso, todos los clientes y aplicaciones que dependen del token digital original se romperán, los usuarios necesitarán actualizar sus clientes para cambiar al nuevo token digital y los contratos inteligentes no tendrán capacidad para mirar al mundo exterior y ver que la necesidad de actualizar se romperá por completo. En medio de todo esto, quienes se oponen al cambio pueden crear una campaña de miedo, incertidumbre y dudas para tratar de convencer a la gente de que tal vez no deberían actualizar a sus clientes después de todo, o actualizar a sus clientes a algún terceras conjunto de reglas (por ejemplo, cambiar la prueba de trabajo), y esto hace que la implementación del cambio sea aún más difícil.
Por lo tanto, podemos decir que en ambos casos, aunque teóricamente existen partidos centralizados o cuasicentralizados que podrían forzar una transición del estado A al estado B, donde el estado B es desagradable para los usuarios pero preferible a los partidos centralizados, hacerlo requiere superar un difícil problema de coordinación. Los problemas de coordinación están en todas partes de la sociedad y a menudo son algo malo; si bien sería mejor para la mayoría de la gente si el idioma inglés se deshiciera de su sistema ortográfico altamente complejo e irregular y creara uno fonético, o si Estados Unidos cambiara al sistema métrico, o si pudiéramos inmediatamente bajar todos los precios y salarios en un diez por ciento en caso de recesión, en la práctica esto requiere que todos se pongan de acuerdo sobre el cambio al mismo tiempo, y esto suele ser muy, muy difícil.
Sin embargo, con las aplicaciones blockchain estamos haciendo algo diferente: Estamos utilizando los problemas de coordinación a nuestro favor., utilizando la fricción que crean los problemas de coordinación como baluarte contra las malas prácticas por parte de actores centralizados. Podemos construir sistemas que tengan la propiedad X y podemos garantizar que preservarán la propiedad X en un alto grado porque cambiar las reglas de X a no X requeriría que un montón de personas aceptaran actualizar su software al mismo tiempo. . Incluso si hay un actor que podría forzar el cambio, hacerlo sería difícil. Este es el tipo de seguridad que se obtiene al validar las reglas de consenso de blockchain por parte del cliente.
Tenga en cuenta que este tipo de seguridad se basa específicamente en la descentralización de los usuarios. Incluso si solo hay un minero en el mundo, todavía existe una diferencia entre una criptomoneda extraída por ese minero y un sistema centralizado similar a PayPal. En el último caso, el operador puede optar por cambiar arbitrariamente las reglas, congelar el dinero de la gente, ofrecer un mal servicio, aumentar sus tarifas o hacer toda una serie de cosas más, y los problemas de coordinación están a favor del operador, como tales sistemas han efectos de red sustanciales y por lo tanto muchos usuarios tendrían que aceptar al mismo tiempo cambiar a un sistema mejor. En el primer caso, la validación del lado del cliente significa que muchos intentos de travesura que el minero podría querer hacer son rechazados por defecto, y el problema de coordinación ahora funciona a favor de los usuarios.
Tenga en cuenta que los argumentos anteriores NO, por ellos mismos, implican que es una mala idea que los mineros sean los actores principales que coordinan y deciden el tamaño del bloque (o en el caso de Ethereum, el límite de gas). Bien puede darse el caso de que, en el caso específico del tamaño del bloque/límite de gas, “el gobierno de mineros coordinados con incentivos alineados” es el enfoque óptimo para decidir este parámetro de política en particular, tal vez porque el riesgo de que los mineros abusen de su poder es menor que el riesgo de que cualquier límite estricto específico elegido resulte tremendamente inapropiado para las condiciones del mercado en un futuro cercano. década después de que se establezca el límite. Sin embargo, no hay nada descabellado en decir que el gobierno de los mineros es la mejor manera de decidir un parámetro de política y, al mismo tiempo, decir que para otros parámetros (por ejemplo, recompensa en bloque) queremos confiar en la validación del lado del cliente para garantizar que los mineros estén restringidos. Ésta es la esencia de la ingeniería de instituciones descentralizadas: se trata de utilizar estratégicamente problemas de coordinación para garantizar que los sistemas sigan satisfaciendo ciertas propiedades deseadas.
Los argumentos anteriores tampoco implican que siempre sea óptimo intentar poner todo en una cadena de bloques, incluso para los servicios que requieren confianza. En general, se pueden obtener al menos algunas ganancias al ejecutar más lógica de negocios en una cadena de bloques, pero a menudo son mucho menores que las pérdidas en eficiencia o privacidad. Y esto está bien; Blockchain no es la mejor herramienta para cada tarea. ¿Cuáles son los argumentos anteriores? do Lo que implica, sin embargo, es que si está creando una aplicación basada en blockchain que contiene muchos componentes centralizados por necesidad, entonces puede obtener ganancias sustanciales adicionales en la minimización de la confianza al brindarles a los usuarios una forma de acceder a su aplicación a través de un cliente blockchain normal ( (p. ej., en el caso de Ethereum, podría ser Mist, Parity, Metamask o Status), en lugar de hacer que utilicen una interfaz web que usted controle personalmente.
Teóricamente, los beneficios de la validación del lado del usuario se optimizan si literalmente cada usuario ejecuta un "nodo completo ideal" independiente: un nodo que acepta todos los bloques que siguen las reglas del protocolo que todos acordaron al crear el sistema y rechaza todos los bloques que lo hacen. no. En la práctica, sin embargo, esto implica pedir a cada usuario que procese cada transacción realizada por todos en la red, lo cual es claramente insostenible, especialmente teniendo en cuenta el rápido crecimiento de los usuarios de teléfonos inteligentes en el mundo en desarrollo.
Hay dos salidas aquí. La primera es que podemos darnos cuenta de que si bien es óptimo Desde el punto de vista de los argumentos anteriores, que todo el mundo ejecuta un nodo completo, ciertamente no es Requisitos. Podría decirse que cualquier cadena de bloques importante que funcione a plena capacidad ya habrá llegado al punto en el que no tendrá sentido que "la gente común" gaste una quinta parte de su espacio en el disco duro para ejecutar un nodo completo, por lo que los usuarios restantes son aficionados y negocios. Mientras haya un número bastante grande de ellos y provengan de diversos orígenes, el problema de coordinación para lograr que estos usuarios se confabulen seguirá siendo muy difícil.
En segundo lugar, podemos confiar en fuerte tecnología de cliente ligero.
Hay dos niveles de "clientes ligeros" que generalmente son posibles en los sistemas blockchain. El primer tipo de cliente ligero, más débil, simplemente convence al usuario, con cierto grado de seguridad económica, de que está en la cadena respaldada por la mayor parte de la red. Esto se puede hacer de manera mucho más económica que verificar toda la cadena, ya que todo lo que los clientes deben hacer es verificar los nonces en los esquemas de prueba de trabajo o en los esquemas de participación de prueba verificar los certificados firmados que indiquen "o el hash raíz del estado es lo que yo digo". es, o puedes publicar este certificado en la cadena principal para eliminar una gran cantidad de mi dinero”. Una vez que el cliente ligero verifica un hash raíz, puede usar árboles Merkle para verificar cualquier dato específico que desee verificar.
¡Mira, es un árbol Merkle!
El segundo nivel es un cliente ligero de “verificación casi completa”. Este tipo de cliente no sólo intenta seguir la cadena que sigue la mayoría; más bien, también intenta seguir sólo cadenas que siguen todas las reglas. Esto se hace mediante una combinación de estrategias; lo más sencillo de explicar es que un cliente ligero puede trabajar junto con nodos especializados (crédito a Gavin Wood por haber inventado el nombre “pescadores”) cuyo propósito es buscar bloques que no son válidos y generar “pruebas de fraude”, mensajes cortos que esencialmente diga “¡Mira! ¡Este bloque tiene un defecto por aquí!”. Los clientes ligeros pueden luego verificar esa parte específica de un bloque y verificar si realmente no es válida.
Si se determina que un bloque no es válido, se descarta; Si un cliente ligero no escucha ninguna prueba de fraude para un bloque determinado durante unos minutos, asume que el bloqueo probablemente sea legítimo. Hay una un poco más de complejidad involucrados en el manejo del caso donde el problema no son los datos que son malos, sino más bien datos que son que falta, pero en general es posible acercarse bastante a detectar todas las formas posibles en que los mineros o validadores pueden violar las reglas del protocolo.
Tenga en cuenta que para que un cliente ligero pueda validar eficientemente un conjunto de reglas de aplicación, esas reglas deben ejecutarse dentro del consenso, es decir, deben ser parte del protocolo o parte de un mecanismo que se ejecuta dentro del protocolo ( como un contrato inteligente). Este es un argumento clave a favor del uso de blockchain tanto para el almacenamiento de datos como para la ejecución de la lógica empresarial, en lugar de solo el almacenamiento de datos.
Estas técnicas de clientes ligeros son imperfectas, ya que se basan en suposiciones sobre la conectividad de la red y la cantidad de otros clientes ligeros y pescadores que están en la red. Pero en realidad no es crucial que trabajen el 100% del tiempo para el 100% de los validadores. Más bien, todo lo que queremos es crear una situación en la que cualquier intento por parte de un cártel hostil de mineros/validadores de impulsar bloques no válidos sin el consentimiento del usuario causará una gran cantidad de dolores de cabeza a muchas personas y, en última instancia, requerirá que todos actualicen su software si desea continuar sincronizando con la cadena no válida. Mientras esto se cumpla, habremos logrado el objetivo de la seguridad mediante fricciones de coordinación.
Fuente: https://vitalik.eth.limo/general/2017/05/08/coordination_problems.html
- Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
- PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
- PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
- PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
- PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
- Desplazamientos de bloque. Modernización de la propiedad de compensaciones ambientales. Accede Aquí.
- Fuente: Inteligencia de datos de Platón.
