Maxim Orlovsky, asociación de estándares LNP/BP
En el documento, proponemos una forma de actualizar la capa 1 de bitcoin (blockchain/timechain) sin un software requerido. La actualización aprovecha las propiedades de la validación del lado del cliente, puede ser gradual, tiene una opción de implementación sin permiso (es decir, no requiere soporte mayoritario o cooperación de mineros) y tendrá la escalabilidad del pedido
La palabra bitcoin ha adquirido múltiples significados, por lo tanto, los distinguimos utilizando términos más específicos. Utilizamos Bitcoin como un término paraguas genérico que denota el sistema en su conjunto, que puede incluir múltiples capas (incluidos algo de futuro) y la idea general del sistema de efectivo electrónico entre pares que se originan en Satoshi Nakamoto. Al mismo tiempo, usamos BTC para denotar bitcoin como escasez digital, dinero y moneda. También distinguimos el consenso de POW de bitcoin (la regla de seleccionar el siguiente productor de bloques), el consenso de Nakamoto (que incluye el consenso de POW mejorado con los medios criptoeconómicos de castigo minero), Bitcoin Blockchain (alternativamente llamado Timechain ) como una implementación actual específica de la capa de bitcoin 1 y Protocolo de bitcoin (BP) como un conjunto de estándares, tecnologías y herramientas para trabajar con las transacciones de Bitcoin en la cadena (en cualquier posible capa 1).
La implementación original de Bitcoin por Satoshi Nakamoto trajo la extraña idea de que todos necesitan verificar las transacciones para todo el mundo. Esta idea recibió el nombre de blockchain , o, a veces, timechain , que se convirtió en un eufemismo para un libro mayor con acceso público. La introducción del libro mayor ha creado dos problemas: ausencia de escalabilidad y mala privacidad; El primero evita que ocurra la adopción y el efecto de redes; El otro contradice el espíritu original Cypherpunk de Bitcoin y representa un riesgo de civilización estratégica (ver inevitabilidad de Cypherpunk para una civilización adecuada y el manifiesto Cyphernox).
La escalabilidad y, en parte, los problemas de privacidad se abordaron luego por la introducción de sistemas de la capa 2, como Lightning Network y otras soluciones propuestas. Entre ellos, la menos fructífera fue la idea de Sidechain, que heredó la mayoría (si no todas) de las limitaciones de tecnología blockchain originales al tiempo que resolvió solo un problema de baja programabilidad, creó una caja de arena para experimentos y, en parte, algunos aspectos de la privacidad. Lightning Network, una solución de capa 2 más exitosa que ya está implementada y operativa, tiene sus propios problemas de escalabilidad debido a la necesidad de liquidez sobre -colateralización, limitaciones del rendimiento del tráfico de chismes (ambos que conducen a la centralización de la red) y disminuyen la seguridad/sin confianza bajo condiciones de capa de base alta [..]. Otras alternativas propuestas, como ARK, requieren varios cambios de capa base (una o dos Forks Softforks), lo que presenta desafíos para la implementación. Finalmente, ninguna de las soluciones de segunda capa existentes o propuestas resuelve los problemas originales de privacidad de la capa base de bitcoin, y otras soluciones de capa-1 centradas en la privacidad (como Coinjoin) todavía no protegen de las autoridades legales e introducen problemas adicionales de fungibilidad de BTC.
Por lo tanto, se puede concluir que es el enfoque de blockchain basado en el libro mayor para la construcción de la capa 1 que debe repensarse por completo para resolver los problemas anteriores. Las primeras ideas en este espacio llegaron con las de Peter Todd en 2016 y 2017 cuando señaló que los propietarios de algún estado (por ejemplo, BTC o cualquier otro contrato con estado) necesitan verificar solo una parte de la historia transaccional, la parte que es directamente relacionado con su propiedad, y omite el resto. Llamó a su enfoque de validación del lado del cliente . Giacomo diseñó un protocolo capaz de crear activos con este enfoque, llamado RGB . En mi trabajo anterior en la Asociación de Normas LNP/BP, pude desarrollar RGB aún más y convertirlo en el primer sistema genérico de contrato inteligente validado con el lado del cliente con un estado rico y una computación completa de Turing, proporcionando suficiente funcionalidad para ejecutar cualquier cosa que Se puede hacer con contratos inteligentes basados en blockchain, pero sin el libro mayor/blockchain que almacena ningún datos del usuario, utilizando directamente las propiedades de gasto anti-doble del protocolo de consenso de POW de Bitcoin. Este sistema se desarrolló públicamente durante el transcurso de cuatro años y se lanzó en abril de 2023.
En la propuesta actual, demostramos que Bitcoin, si se proporciona con una capa valiosa del lado del cliente (como RGB), puede actualizarse a un sistema sin las propiedades limitantes del Ledger público (blockchain) y, al tiempo que preserva el protocolo de consenso POW, Se puede basar en una nueva capa de cadena 1 escalable (Codenammened Prime ). Esta capa podrá alojar un número teóricamente indefinido de transacciones (al menos miles de millones por minuto) ya que el almacenamiento del estado, la informática y la validación se moverán a la capa validada del lado del cliente anterior. Tal diseño no requiere una red de rayos u otras capas de escalabilidad y pago en la parte superior y escala en el peor de los casos como
El protocolo tiene tres opciones de implementación (sin permiso, activado por mineros y softfork), y los dos primeros no requieren ningún tenedor blando (o duro). Las opciones son independientes, pero también se pueden implementar de manera consecuente.
La propuesta proporciona varios beneficios a Bitcoin como efectivo digital:
Algunos inconvenientes relativos del sistema propuesto son:
El sistema propuesto (Codenomed Prime ) consta de cuatro componentes principales:
Estos componentes son conjuntamente equivalentes en su funcionalidad a un libro mayor de tipo blockchain; Sin embargo, en nuestro diseño se abstraen, proporcionando mucha más escalabilidad y privacidad que cualquier otro sistema de blockchain.
En su fundación, Prime ejecuta un servicio de marca de tiempo, creando una secuencia de encabezados, cada uno que se compromete a una raíz de árbol de Merkle de los datos externos validados del lado del cliente:
classdiagram
Dirección LR
`Cabeze n` <|-` Header N+1`
Clase `Encabezado n` {
Prev_comiteo
merkle_root
merkle_tree_height
marca de tiempo
// campos de pow
tlv_extensions
}
Clase `encabezado N+1` {
Prev_comiteo
merkle_root
merkle_tree_height
marca de tiempo
// campos de pow
tlv_extensions
}
Cada encabezado está equipado con una extensión TLV opcional, que puede usarse para futuras actualizaciones de protocolo; Su tamaño es independiente del número de transacciones contenidas en el árbol de Merkle de los datos validados del lado del cliente y es del orden de 100 bytes (dependiendo de los datos TLV).
Prime no proporciona ninguna protección contra el doble gasto; Será proporcionado por la parte validada del lado del cliente del sistema. Las únicas partes del sistema de marca de tiempo que se validan (reglas de consenso) son:
Los encabezados Prime son la única información que debe estar disponible pública y globalmente; Esto se puede lograr utilizando una red P2P distribuida.
Los árboles de Merkle de prueba ( PMT ) son una estructura intermedia y efímera que une datos validados del lado del cliente con los encabezados. Los PMT son producidos por mineros y se ponen a disposición del público a través de los mismos o algún otro medio que los encabezados; Sin embargo, a diferencia de los encabezados, no están obligados a persistir. Cada usuario de la red rastrea todos los PMT nuevos, extrae parte de la información relacionada con el estado que posee, lo guarda en su propio alijo de datos validados del lado del cliente y descarta el resto del PMT.
Debido a la naturaleza efímera, ausencia de validación y no es necesario conocer el contenido de PMT para minería el siguiente encabezado, el tamaño de PMT no afecta la escalabilidad del sistema. Por lo tanto, el PMT puede ser de tamaño (múltiple) de gigabytes, comprometiéndose con miles de millones y miles de millones de transacciones.
Las hojas de los árboles contienen testigos que cierran los recursos de uso único: un mecanismo descrito en detalle en la siguiente sección. Los PMT se construyen de acuerdo con el estándar LNPBP-4 del esquema de compromiso determinista de múltiples protocolo y se usan en RGB hoy para alojar compromisos en las transacciones de bitcoin (tanto en la cadena como en los protocolos internos como Lightning). Esto significa que cada sol de uso único tiene una ubicación predefinida única en el PMT, de modo que un solo camino de merkle y un testigo de la hoja es suficiente para demostrar el cierre, o ausencia de cierre, de un sello de uso único específico en el encabezado dado. Los usuarios realizan un seguimiento de un conjunto de sus sesiones de uso único que aún no se han cerrado (análogo de UTXO) y extraen pruebas relativas de cada PMT recientemente producido. Si sus sellos no estaban cerrados, estas son las pruebas de una no operación (ya que el testigo demuestra que un sellado de un solo uso diferente está cerrado en ese camino).
Las pruebas constituyen una parte en crecimiento dependiente del tiempo de la historia validada del lado del cliente. Los requisitos de memoria para un nodo crecerán de manera dependiente del tiempo
dónde
Esto es logarítmicamente mejor que la escalabilidad de cualquier nodo blockchain, donde los requisitos de memoria están creciendo como
dónde
dónde
El
dónde
El protocolo de sellado de un solo uso evita ataques de doble gasto en el sistema.
Los servicios de uso único (o sellos ) son una forma especial de compromiso criptográfico propuesto por Peter Todd. El primitivo se puede comparar con otras formas de compromisos criptográficos que incluyen funciones hash y marpadina de tiempo:
Se proporciona más información sobre la construcción de sesiones de un solo uso en el estándar LNPBP-8. Prime utiliza una forma especialmente diseñada de sesiones de uso único que es diferente de la utilizada en los protocolos existentes (como RGB).
La definición de un sello único consiste en dos componentes:
unique_id : Identificador generado por el usuario globalmente único, que se puede generar deterministamente a partir del número de salida de la operación de operación de contrato Contract_ID, la operación y la operación del contrato;spending_conditions_cmt : Compromiso (hash) de las condiciones bajo las cuales el sello puede cerrarse en el futuro (similar a scriptPubkey en la salida de la transacción de Bitcoin). Los sellos se definen en el sistema de contrato inteligente validado del lado del cliente (RGB o RGB-Like). Cada sello puede tener un estado asignado (como en RGB), por ejemplo, el saldo BTC o cualquier otro datos ricos. Cuando a un usuario le gusta actualizar ese estado, o transferir su propiedad a otro usuario, se debe preparar una transición de estado , definiendo nuevos sellados de uso único y el nuevo estado. A continuación, se construye un testigo que cierre que se construye un sello único, comprometiéndose con los datos de transición de estado y proporcionando un script de origen, coincidir con el compromiso de las condiciones de gasto y los datos que satisfacen ese script/condiciones. La propuesta resume de un sistema de secuencias de comandos utilizado (puede ser la simplicidad, el aluvm como en RGB hoy, y con la esperanza de no EVM :); El motor de secuencias de comandos se puede especificar utilizando el campo version , de modo que los nuevos motores u códigos de operación se pueden introducir con el tiempo (ver sección de actualización):
classdiagram
Dirección LR
Definición <|- testigo: unique_id
Definición de clase {
único_id
gastar_conditions_cmt
}
testigo de clase {
versión
único_id
state_transition_cmt
GESTING_CONDITIONS_SRC
satisfacción_data
}
El testigo se pone en la forma explícita dentro de una hoja de un ptree y se proporciona a los mineros, construyendo el Ptree y los encabezados. La hoja debe colocarse dentro del árbol de Merkle determinista con respecto al sello unique_id , por ejemplo en la ranura
Merkle Path to the Leaf Matching unique_id , junto con el contenido de la hoja (que proporciona datos de testigos) permite verificar que cada sello de uso único se cerrara una vez y solo una vez en la historia de un contrato inteligente, y que estaba cerrado satisfaciendo el guión de guión condiciones. Tenga en cuenta que las pruebas deben acumularse para cada sola de uso de un unique_id uso desde la hora de su definición hasta el cierre, un requisito para demostrar que el sello no se cerró en el medio. Estas pruebas, siempre que demuestren diferentes unique_id , pueden omitir las condiciones de gasto sensibles a la privacidad Código fuente y datos de satisfacción, proporcionando solo su hash; Por lo tanto, los testigos históricos pueden ser de tamaño fijo. Como se mencionó anteriormente, para fines de escalabilidad, el historial de pruebas también se puede comprimir aún más utilizando pruebas de conocimiento cero.
El sistema, cuando se implementa con una opción sin permiso, requerirá su propio protocolo de consenso. La seguridad del protocolo no es crítica, ya que está vinculada a la seguridad de Bitcoin POW con un mecanismo dedicado que se describe a continuación. El único requisito para el consenso es ser resistente a la censura, lo que significa un conjunto abierto de mineros/validadores sin identidad. Los únicos dos protocolos de consenso que se sabe que satisfacen estas propiedades son la variante cripsinosa de POW y Ouroboros del consenso BFT asegurado criptoeconómicamente por las recompensas de mineros.
El servicio de campaña de tiempo no acuña ninguna criptomoneda, y los mineros son recompensados con tarifas del día 1. RGB u otro protocolo de contrato inteligente valorado en el día 1, que especifica medios de pago (BTC (BTC , stablecoin o pagos tokenizados). Los mineros deben participar en una red P2P anónima sin permiso, donde los usuarios de los protocolos publican a sus testigos equipados con transacciones que pagan una tarifa a "quien mines el próximo encabezado". Los mineros incluyen estas transacciones en su historial validado del lado del cliente y al hacer eso tiene la capacidad de usar los fondos ganados en el futuro.
En el momento del sistema, lanza una salida dedicada de "cualquiera de gasto de canal" con una cantidad de SATS por encima del húmedo se crea en la cadena de bloques de bitcoin. La información sobre este UTXO se convierte en parte de la Génesis y sirve como una definición de un sello minero . Un minero que resuelve el desafío POW debe gastar esa salida y dentro de la transacción de bitcoin de gasto proporciona un compromiso de tapret con el encabezado minado y un nuevo recurso de uso único de "cualquiera de nadie" para el próximo minero. Esto ancla el encabezado creado a la cadena de bloques de bitcoin de una manera única, de modo que la única secuencia de encabezado de tiempo de tiempo válido es la que sigue esta secuencia de sesiones de un solo uso.
Si una parte gasta el recurso de uso único minero actual sin crear un compromiso, o comprometerse con un encabezado sin el prisionero de guerra suficiente, dicho cierre se considera inválido; En este caso, cualquier parte puede crear una transacción especial de Bitcoin que proporcione información OP_RETURN de identificación pública ("anuncio") sobre un nuevo minero de uso único ( reinicio del protocolo ); Solo el primer anuncio OP_RETURN que se cierra con un procedimiento adecuado se considera válido bajo las reglas de consenso.
La anclaje de Selel-Selal POW representa un protocolo de consenso completo que puede ser ejecutado por el sistema sin ningún otro consenso adicional (POW o BFT). Alternativamente, se puede combinar con un consenso secundario con una regla de que, a menos que la seguridad del segundo protocolo de consenso sea menor que la seguridad de Bitcoin POW, el POW de bitcoin tiene la prioridad, con un cambio automático al consenso secundario como un consenso principal cuando esto La condición no se cumple.
Deliberadamente no abordamos la cuestión de la estructura de la red P2P en esta propuesta, ya que múltiples sistemas alternativos pueden coexistir y competir de manera impulsada por el mercado. En cambio, dado que las propiedades de la red son importantes para los objetivos del proyecto, definimos los requisitos generales para la selección de una red P2P:
En el momento actual de tiempo no vemos una red que cumpla con las propiedades mencionadas anteriormente; Sin embargo, vemos varias redes con el potencial de desarrollar hacia ellas:
Planeamos trabajar en el proyecto Renostr, utilizando nuestro trabajo anterior del protocolo de tormenta y utilizando el cifrado de extremo a extremo de estilo BIP-324. Otros proyectos pueden crear soluciones alternativas, y el mercado debe seleccionar la mejor opción.
Vemos tres pasos, u opciones, en cómo se puede implementar la solución propuesta en Bitcoin. Cada uno de los pasos es opcional; El sistema puede funcionar sin uno o dos de ellos. Además, cada opción tiene sus propias compensaciones, sin embargo, si se implementa como pasos consecuentes, estas compensaciones se resuelven gradualmente.
El sistema se puede lanzar de forma independiente desde el bitcoin timechain, con el consenso anclado a la seguridad de Bitcoin POW a través de un mecanismo dedicado basado en sellados de uso único (que describimos en el documento). Esto no requiere ningún cambio en el lado del minero ni en cualquier Bitcoin Soft/Hardforks, sin embargo, con esta configuración, BTC puede transferirse al nuevo sistema sin confianza solo de una manera, y la otra forma requerirá una federación.
Los mineros de bitcoin comienzan a procesar transacciones principales y ponen compromiso con los encabezados de servicio de estampado de tiempo a la bitcoin blockchain coinbase, como lo hacen en un caso de minería fusionada. Esto elimina la necesidad de un consenso principal dedicado, pero es vulnerable a los ataques de poder del hash, lo que requiere que la gran mayoría de los mineros se unan al protocolo antes de su despliegue.
La propuesta no requiere ningún SoftFork específico, sin embargo, con las reglas actuales de consenso de Bitcoin, no puede proporcionar una forma confiable para que BTC se mueva del nuevo sistema Prime a la cadena de bloques de Bitcoin. Si bien no vemos esto como un requisito (Prime tiene demasiados beneficios sobre blockchain de tal manera que consideramos que blockchain ya está muerto a largo plazo), a corto plazo esto puede presentar un desafío para la adopción de la plataforma.
Hay muchas propuestas de tarifa blanda diferentes que pueden permitir dicha funcionalidad. Se dividen en dos categorías principales:
La adopción de cualquiera de estas propuestas permitirá un PEG-Out sin confianza para BTC en la plataforma Prime. Nuestras propias preferencias van después de los códigos operacionales que habilitan el conocimiento cero, ya que tienen muchos otros beneficios y no proporcionan compensaciones inevitables en Drivechains.
La actualización de un sistema validado del lado del cliente es muy diferente de la actualización de la red blockchain o p2p (como rayos). Esto es causado por el hecho de que Blockchains son protocolos de consenso que son máquinas de estado completamente replicadas, mientras que la validación del lado del cliente utiliza una replicación parcial. Esto, por un lado, hace que sea más simple actualizar el sistema en piezas relacionadas con el estado desconocido, pero por otro lado, debido a la ausencia de garantías no fruncidas en un estado accesible a nivel mundial proporcionado por la red , es mucho más difícil coordinar cualquier actualización.
En otras palabras, las actualizaciones de validación del lado del cliente son fundamentalmente diferentes a las forks y las forks de blockchain, y requieren la introducción de nuevos conceptos y términos.
Si algo no fue válido y se ha vuelto válido después de una actualización (llamamos a este cambio rápido ), todos los usuarios existentes no se verán afectados: ya poseen y administran el estado que es válido. Sin embargo, es posible que no puedan interactuar con los usuarios que ejecutan versiones anteriores del software, un problema solucionable si sus pares aceptan actualizar. La actualización no presenta ningún riesgo para esos pares, ya que no utilizarán ninguno de los estados que poseen, y la actualización no tocará los datos históricos.
Por otro lado, la situación en la que algo era válido, y se volvió inválido bajo las nuevas reglas, es muy diferente: los usuarios pueden perder su estado existente para siempre y deben oponerse a una actualización tanto como sea posible. Llamamos a tales actualizaciones de retroceso , y los vemos como aceptables solo si se descubrió un error crítico: la actualización estará "coordinada" por el deseo de usuarios sinceros/no tratos para evitar problemas introducidos por el error.
Si el sistema inspirado en RGB o RGB se usa como un componente de contrato inteligente, las actualizaciones de esta parte tendrán otra característica distintiva. RGB aísla cada programa ("contrato inteligente") en un sandbox; Y un contrato, una vez que se emite, no puede actualizarse a la nueva versión del protocolo. La única forma de actualizar es producir un nuevo contrato cuando un emisor (o partes a los que fue delegado por los emisores, incluida la comunidad) hará una transferencia estatal del antiguo contrato al nuevo, y cada uno de los contratos. Los propietarios estarán de acuerdo en eso.
Como beneficio secundario, este enfoque permite la introducción gradual de nuevas características, instrucciones, etc., no alcanzables en el mundo de blockchain: los emisores de los nuevos contratos no dependen de las versiones de protocolo anteriores y pueden proponer soluciones más avanzadas sin ningún riesgo de actualización adicional o de actualización o de actualización adicional Coordinación de la comunidad.
El autor está agradecido con Giacomo Zucco, quien era la persona que se inspiraba con la idea de eliminar la dependencia de Bitcoin de blockchain limitada y ver la validación del lado del cliente como un camino a seguir. Múltiples discusiones con él y Peter Todd a lo largo de los años habían ayudado a diseñar muchas partes del sistema. Entre otros, el autor quisiera mencionar a Alex Kravets, Federico Tenga, Olga Ukolova, que fueron los interlocutores que pasaron muchas horas discutiendo asuntos relacionados con la validación del lado del cliente, los defectos de blockchain y los diseños sin blockchain.
