Desde su inicio en 2009, Bitcoin (BTC), como la primera criptomoneda del mundo, se ha convertido gradualmente en la piedra angular de los activos digitales y las finanzas descentralizadas. Sin embargo, a medida que aumenta el número de usuarios y volúmenes de transacciones, varios problemas con la red BTC se han vuelto cada vez más evidentes:

• Altas comisiones de transacción: Cuando la red de Bitcoin está congestionada, los usuarios necesitan pagar tarifas más altas para asegurarse de que sus transacciones se confirmen rápidamente.
• Tiempo de Confirmación de Transacción: La cadena de bloques de Bitcoin genera un nuevo bloque aproximadamente cada 10 minutos, lo que significa que las transacciones en cadena típicamente requieren múltiples confirmaciones de bloques antes de considerarse finales.
• Limitaciones del contrato inteligente: el lenguaje de secuencias de comandos de Bitcoin es limitado en funcionalidad, lo que dificulta la implementación de contratos inteligentes complejos.

En este artículo, nos referimos a tecnologías como laRed de Rayos, Sidechains y Rollup colectivamente como soluciones de escalado BTC Layer2. Estas tecnologías permiten transacciones rápidas y de bajo costo manteniendo la descentralización y seguridad de la red BTC. La introducción de tecnologías Layer2 puede mejorar la velocidad de las transacciones, reducir los costos de transacción, optimizar la experiencia del usuario y expandir la capacidad de la red, brindando un soporte técnico e innovación crucial para el desarrollo futuro de BTC.

Actualmente, Beosin se ha convertido en el socio de seguridad oficial de varios proyectos de capa 2 de BTC como Merlin Chain y ha auditado múltiples protocolos del ecosistema BTC, incluidos Bitmap.Games, Surf Protocol, Savmswap y Mineral. En auditorías pasadas, numerosas cadenas públicas conocidas, como Ronin Network, Clover, Self Chain y Crust Network, han superado con éxito las auditorías de seguridad de cadenas públicas de Beosin. Beosin ahora ofrece una solución de auditoría integral para BTC Layer2, brindando servicios de auditoría de seguridad confiables y exhaustivos para todo el ecosistema BTC.

La Red Lightning

El concepto inicial detrás de la Red Lightning se conocía como un 'canal de pago'. La filosofía de diseño era actualizar continuamente el estado de las transacciones no confirmadas a través de la sustitución de transacciones hasta que finalmente se transmitieran a la red Bitcoin. Cuando Satoshi Nakamoto creó Bitcoin en 2009, ya había propuesto la idea de los canales de pago, incluso incluyendo un código preliminar para los canales de pago en Bitcoin 1.0. Este borrador permitía a los usuarios actualizar el estado de la transacción antes de que fuera confirmado por la red. Sin embargo, no fue hasta la publicación del libro blanco titulado La Red Lightning de Bitcoin: Pago instantáneo escalable fuera de la cadenaque la Red Lightning realmente cobró vida y llamó la atención del público.

Hoy en día, la implementación de los canales de pago y la Red Lightning se ha vuelto bastante madura. Hasta ahora, la Red Lightning consta de 13,325 nodos y 49,417 canales, con un total de 4,975 BTC en juego.

https://1ml.com/

En la Red Lightning, garantizar la seguridad de los activos de los usuarios durante las transferencias es crucial. A continuación, explicaremos cómo opera la Red Lightning y cómo protege la seguridad de los activos de los usuarios, en función de la escala de los nodos de la red.

Ambas partes involucradas envían dos transacciones a la red principal de Bitcoin: una para abrir el canal y otra para cerrarlo. El proceso generalmente implica tres pasos:

1. Apertura de canal:

Primero, ambos usuarios apuestan Bitcoin en una billetera multi-firma en la red BTC a través de la Red Lightning. Una vez que el Bitcoin se apuesta y se bloquea con éxito, se abre el canal de pago, lo que permite a ambas partes realizar transacciones fuera de la cadena dentro de este canal.

2.Off-chain transactions:

Una vez que se abre el canal, todas las transacciones de transferencia entre los usuarios se procesan dentro de la Red Lightning, y no hay límite en el número de estas transacciones fuera de cadena. Estas transacciones no necesitan ser enviadas inmediatamente a la red principal de Bitcoin, sino que se completan al instante a través del mecanismo fuera de cadena de la Red Lightning.

Este método de procesamiento fuera de la cadena aumenta significativamente la velocidad y eficiencia de las transacciones, evitando la congestión en la red principal de Bitcoin y las altas comisiones de transacción.

3. Cierre de canal y liquidación de libros contables:

Cuando cualquiera de los usuarios decide salir del canal, ocurre un asentamiento final del libro mayor. Este proceso garantiza que todos los fondos en el canal se distribuyan de acuerdo con el estado más reciente. Luego, ambos usuarios retiran sus saldos liquidados respectivos de la billetera multi-firma, reflejando la distribución real de fondos en el momento en que se cierra el canal. Finalmente, la transacción que representa el estado final del libro mayor se envía a la red principal de Bitcoin.

Las ventajas de la Red Lightning incluyen:

• Velocidad de transacción aumentada:
  La Lightning Network permite a los usuarios realizar transacciones fuera de la cadena, lo que significa que las transacciones pueden completarse casi al instante sin tener que esperar los tiempos de confirmación de bloque. Esto permite velocidades de transacción de segundo nivel, mejorando enormemente la experiencia del usuario.
• Privacidad mejorada:
  Las transacciones fuera de la cadena en la Red Lightning no necesitan ser registradas públicamente en la cadena principal de Bitcoin, lo que mejora la privacidad de las transacciones. Solo la apertura y cierre de canales deben ser registrados en la cadena principal, por lo que las actividades de transacción de los usuarios no se revelan por completo.
• Soporte para Micro-Pagos:
  La Red Lightning es especialmente adecuada para manejar micro pagos, como pagos de contenido y pagos entre dispositivos IoT. Las transacciones tradicionales de Bitcoin, debido a las altas tarifas, no son ideales para micro pagos frecuentes, pero la Red Lightning aborda este problema.

Los desafíos enfrentados por la Red Lightning incluyen:

• Liquidez de la red:
  La Red Lightning depende de que el Bitcoin esté prebloqueado en el canal. Esto significa que los usuarios deben depositar suficiente Bitcoin en sus canales de pago con antelación para facilitar las transacciones. La liquidez insuficiente puede provocar fallos en los pagos, especialmente en pagos más grandes.
• Enrutamiento:
  Encontrar una ruta efectiva desde el remitente hasta el destinatario puede ser un problema complejo, especialmente a medida que la red crece en escala. A medida que aumenta el número de nodos de red y canales, asegurar la finalización exitosa del pago se vuelve más desafiante.
• Fideicomiso custodial: Los nodos pueden ser susceptibles a ataques maliciosos, y los usuarios necesitan confiar en que los nodos a los que están conectados no intentarán robar fondos. También está la cuestión de si los nodos pueden prevenir filtraciones de claves privadas.
• Normas técnicas e interoperabilidad: Se requieren estándares técnicos y protocolos consistentes para garantizar la interoperabilidad entre diferentes implementaciones de la Red Lightning. Actualmente, varios equipos de desarrollo están trabajando en diversas implementaciones de la Red Lightning, lo que podría llevar a problemas de compatibilidad.
• Problemas de privacidad: Aunque la Red Lightning mejora la privacidad de las transacciones de Bitcoin, la información de las transacciones aún podría rastrearse o analizarse. Además, los operadores de nodos de la red pueden ver las transacciones que pasan por sus nodos, comprometiendo potencialmente parte de la privacidad.

La seguridad de la Red Lightning impacta directamente en la escalabilidad fuera de cadena de Bitcoin y la seguridad de los fondos de los usuarios. Por lo tanto, además de los elementos de auditoría comunes para las cadenas públicas (detallados en el apéndice al final de este documento), la Red Lightning también necesita abordar los siguientes riesgos clave de seguridad:

• Congestión del canal:
  Evaluar la exhaustividad del diseño del sistema de la Red Lightning para asegurarse de que no sea susceptible a ataques de denegación de servicio que podrían provocar congestión de canales.
• Interferencia de canal:
  Evaluar la seguridad de la estructura del canal de la Red Lightning para asegurarse de que no sea vulnerable a los ataques de bloqueo del canal.
• Bloqueo y desbloqueo de activos del canal:
  Revisar los procesos para bloquear y desbloquear activos en la Red Lightning para garantizar que las transferencias de fondos entre on-chain y off-chain sean seguras y fiables durante la apertura o cierre de canales de pago.
• Actualizaciones del estado y cierre del canal:
  Evaluar los procesos para actualizar el estado de los canales y el mecanismo de cierre forzado para garantizar que, en caso de una situación anormal, se pueda reconocer y ejecutar con precisión el estado más reciente.
• Bloqueos de tiempo y contratos con bloqueo de tiempo hash (HTLC):
  Evaluar la implementación de HTLCs para garantizar que las condiciones de bloqueo de tiempo y bloqueo de hash se apliquen correctamente, evitando posibles pérdidas de fondos debido a problemas de ventana de tiempo.
• Dependencia de marcas de tiempo de Blockchain:
  Evaluar la dependencia de la Lightning Network de las marcas de tiempo del blockchain de Bitcoin para garantizar la sincronización adecuada de los tiempos on-chain y off-chain, evitando ataques basados en el tiempo.
• Seguridad del algoritmo de enrutamiento: Examinar la eficiencia y la seguridad de los algoritmos de enrutamiento para prevenir riesgos de exposición de privacidad y manipulación maliciosa del enrutamiento.
• Almacenamiento de canales y recuperación de datos:
  Verifique el mecanismo de almacenamiento del canal y la estrategia de recuperación de datos para garantizar que los estados del canal puedan ser restaurados en caso de fallas del nodo o desconexiones inesperadas, evitando la pérdida de fondos.

Cadenas laterales

A diferencia de la Red Lightning, una sidechain es una cadena de bloques independiente que opera en paralelo a la cadena principal (como la cadena de bloques BTC) e interactúa con ella a través de un mecanismo conocido como un anclaje bidireccional (2WP). El propósito de las sidechains es permitir funcionalidades adicionales y escalabilidad sin alterar el protocolo de la cadena principal.

Una sidechain, como una blockchain independiente, tiene su propio mecanismo de consenso, nodos y reglas de procesamiento de transacciones. Puede adoptar diferentes tecnologías y protocolos según las necesidades de escenarios de aplicación específicos. A través del mecanismo de anclaje bidireccional, la sidechain se comunica con la mainchain, asegurando que los activos se puedan transferir libre y seguramente entre ellos. El funcionamiento del mecanismo de anclaje bidireccional generalmente implica los siguientes pasos:

1. El usuario bloquea BTC en la cadena principal. Luego, una entidad de confianza obtiene y utiliza la Verificación de Pago Simplificada (SPV) para confirmar si la transacción de bloqueo del usuario ha sido confirmada.

2. La entidad de confianza emite una cantidad equivalente de tokens al usuario en la cadena lateral.

3. Después de completar sus transacciones, el usuario bloquea las tokens restantes en la cadena lateral.

4. Después de verificar la legitimidad de las transacciones, la entidad de confianza desbloquea y libera el valor correspondiente de BTC al usuario en la mainchain.

Nota 1: Las entidades de confianza juegan un papel crítico en el mecanismo de anclaje bidireccional, gestionando el bloqueo y la liberación de activos. Estas entidades deben poseer altos niveles de confianza y capacidad técnica para garantizar la seguridad de los activos de los usuarios.

Nota 2: La verificación SPV permite a un nodo verificar la validez de una transacción específica sin descargar toda la cadena de bloques. Los nodos SPV solo necesitan descargar los encabezados de bloque y usar el Árbol de Merkle para verificar si la transacción está incluida en el bloque.

Proyectos de cadenas laterales representativos

CKB (Red Nervos) \
Nervos Network es un ecosistema de blockchain público de código abierto diseñado para aprovechar los beneficios de seguridad y descentralización del mecanismo de consenso de Prueba de Trabajo (PoW) de Bitcoin, al mismo tiempo que introduce un modelo UTXO más escalable y flexible para manejar transacciones. En su núcleo se encuentra la Base de Conocimiento Común (CKB), una blockchain de Capa 1 construida en RISC-V y que utiliza PoW como su mecanismo de consenso. Extiende el modelo UTXO al modelo de Celda, lo que le permite almacenar cualquier dato y admitir scripts escritos en cualquier lenguaje para ejecutarse como contratos inteligentes on-chain.

Stacks

Stacks conecta cada bloque de Stacks con un bloque de Bitcoin a través de su mecanismo de Prueba de Transferencia (PoX). Para facilitar el desarrollo de contratos inteligentes, Stacks ha diseñado el lenguaje de programación Clarity. En Clarity, obtener-información-del-bloque-de-quema?La función permite la entrada de una altura de bloque de Bitcoin para recuperar el hash del encabezado del bloque, mientras que altura-de-bloque-de-quemaLa palabra clave recupera la altura del bloque actual de la cadena Bitcoin. Estas funciones permiten que los contratos inteligentes de Clarity lean el estado de la cadena base de Bitcoin, lo que permite que las transacciones de Bitcoin activen contratos. Al ejecutar automáticamente estos contratos inteligentes, Stacks extiende la funcionalidad de Bitcoin. Para un análisis detallado de Stacks, puede consultar el artículo de investigación anterior de Beosin: ¿Qué es Stacks? ¿Qué desafíos podría enfrentar Stacks, la red de capa 2 de BTC?

Ventajas de las cadenas laterales

• Las sidechains pueden adoptar diferentes tecnologías y protocolos, lo que permite diversos experimentos e innovaciones sin afectar la estabilidad y seguridad de la mainchain.
• Las sidechains pueden introducir características no presentes en la mainchain, como contratos inteligentes, protección de la privacidad y emisión de tokens, enriqueciendo los escenarios de aplicación del ecosistema blockchain.

Desafíos de las cadenas laterales

• Las sidechains tienen mecanismos de consenso independientes, que pueden no ser tan seguros como la cadena principal de BTC. Si el mecanismo de consenso de una sidechain es débil o tiene vulnerabilidades, podría llevar a un ataque del 51% u otras formas de ataques, poniendo en peligro la seguridad de los activos de los usuarios. La seguridad de la cadena principal de BTC depende de su inmenso poder de hash y su amplia distribución de nodos, que una sidechain puede que no pueda igualar.
• Implementar el mecanismo de pata de dos vías requiere algoritmos criptográficos y protocolos complejos. Si hay vulnerabilidades dentro de este mecanismo, podría conducir a problemas en las transferencias de activos entre la cadena principal y la cadena lateral, potencialmente resultando en pérdida o robo de activos.
• Para equilibrar la velocidad y la seguridad, la mayoría de las sidechains son más centralizadas que la mainchain.

La capa 2 es un sistema de blockchain completo, por lo que los elementos generales de auditoría para blockchains públicos también se aplican a las cadenas laterales. Para más detalles, consulte el apéndice al final de este artículo.

Además, debido a sus características únicas, las sidechains requieren auditorías adicionales:

• Seguridad del Protocolo de Consenso:
  Revisar si el protocolo de consenso de la cadena lateral (por ejemplo, PoW, PoS, DPoS) ha sido validado y probado exhaustivamente en busca de posibles vulnerabilidades o vectores de ataque, como ataques del 51% o ataques de largo alcance.
• Seguridad del nodo de consenso:
  Evaluar la seguridad de los nodos de consenso, incluida la gestión de claves, la protección de nodos y las copias de seguridad redundantes, para evitar que los nodos sean comprometidos o abusados.
• Bloqueo y liberación de activos:
  Examine el mecanismo de anclaje bidireccional entre la cadena lateral y la cadena principal para asegurar que los contratos inteligentes responsables de bloquear y liberar activos sean seguros y confiables, evitando el doble gasto, la pérdida de activos o fallas en el bloqueo.
• Verificación entre Cadenas:
  Verifique la precisión y seguridad de la verificación de cadena cruzada para garantizar que el proceso sea descentralizado y a prueba de manipulaciones, evitando fallos de verificación o verificaciones maliciosas.
• Auditoría de código de contrato inteligente:
  Realice una auditoría exhaustiva de todos los contratos inteligentes que se ejecutan en la cadena lateral, detectando posibles vulnerabilidades o puertas traseras, especialmente en la lógica de los contratos que manejan operaciones entre cadenas.
• Mecanismo de actualización:
  Revisar la seguridad del mecanismo de actualización del contrato inteligente, asegurando que existan procesos de auditoría y consenso de la comunidad adecuados para evitar actualizaciones maliciosas o manipulación del contrato.
• Comunicación entre nodos:
  Inspeccionar la seguridad del protocolo de comunicación entre los nodos de la cadena lateral, asegurando el uso de canales cifrados para prevenir ataques de intermediarios o brechas de datos.
• Comunicación entre cadenas:
  Evaluar los canales de comunicación entre la cadena lateral y la cadena principal para garantizar la integridad y autenticidad de los datos, evitando que la comunicación sea interceptada o manipulada.
• Marca de tiempo y tiempo de bloque:
  Verifique el mecanismo de sincronización de tiempo de la cadena lateral para garantizar la consistencia y precisión en el tiempo de generación de bloques, evitando ataques o retrocesos de bloques causados por discrepancias de tiempo.
• Seguridad de la gobernanza en cadena:
  Revisar el mecanismo de gobernanza de la cadena lateral para garantizar transparencia y seguridad en los procesos de votación, propuesta y toma de decisiones, evitando el control malicioso o los ataques.
• Auditoría de Economía de Token:
  Examine el tokenomics del sidechain, incluyendo la distribución de tokens, los mecanismos de incentivos y los modelos de inflación, asegurando que los incentivos económicos no conduzcan a comportamientos maliciosos o inestabilidad del sistema.
• Mecanismo de tarifas:
  Revisar el mecanismo de tarifas de transacción de la cadena lateral para asegurar que se alinee con las necesidades tanto de los usuarios de la cadena principal como de la cadena lateral, evitando la manipulación de tarifas o la congestión de la red.
• Seguridad de activos:
  Auditar el mecanismo de gestión de activos en cadena para garantizar que los procesos de almacenamiento, transferencia y quema de activos sean seguros y fiables, sin riesgo de acceso no autorizado o robo.
• Gestión de claves:
  Inspeccionar la estrategia de gestión de claves de la cadena lateral para garantizar la seguridad de las claves privadas y el control de acceso, evitando fugas o uso indebido de claves.

Rollup

Rollup es una solución de escalamiento de Capa 2 diseñada para mejorar la capacidad de procesamiento y eficiencia de transacciones en la cadena de bloques. Al agregar un gran número de transacciones ("Agrupando") y procesarlas fuera de la cadena, reduce la carga en la cadena principal, enviando solo los resultados finales de vuelta a ella.

Rollup viene en dos tipos principales: zk-Rollup y op-Rollup. Sin embargo, a diferencia de Ethereum, la falta de Turing completeness de Bitcoin impide el uso de contratos inteligentes para la verificación de pruebas de conocimiento cero (ZKP) directamente en su red. Esto significa que las soluciones tradicionales de zk-Rollup no pueden implementarse en Bitcoin. Entonces, ¿cómo se puede utilizar zk-Rollup para lograr la escalabilidad de la Capa 2 de Bitcoin? Exploremos el proyecto de la Red B² como ejemplo:

Para realizar la verificación de conocimiento cero en Bitcoin, B² Network ha desarrollado un script de Taproot que integra la verificación de prueba de conocimiento cero de zk-Rollup con el mecanismo de desafío de incentivos de op-Rollup. Así es como funciona:

1. La red B² primero agrega todas las transacciones de usuario en un Rollup.
2. Un secuenciador ordena luego estas transacciones de Rollup, almacenándolas en almacenamiento descentralizado y procesándolas a través de un zkEVM.
3. Después de sincronizar el estado de la cadena Bitcoin, zkEVM procesa las ejecuciones de contratos y otras transacciones, consolidando los resultados y enviándolos al agregador.
4. El probador genera una prueba de conocimiento cero y la envía al agregador, que combina las transacciones y la prueba y las reenvía a los Nodos B².
5. Los nodos B² verifican la prueba de conocimiento cero y crean un script de Taproot basado en los datos de Rollup almacenados en el almacenamiento descentralizado.
6. El Taproot, que es un UTXO con un valor de 1 satoshi, contiene la Inscripción B² en su estructura de datos, almacenando todos los datos de Rollup, mientras que el Tapleaf almacena los datos de verificación de todas las pruebas. Después de pasar el mecanismo de desafío de incentivos, se envía a Bitcoin como un compromiso basado en zk-proof.

Ventajas de Rollup:

• Rollup hereda las características de seguridad y descentralización de la cadena principal. Al enviar regularmente datos de transacciones y estado a la cadena principal, garantiza la integridad y transparencia de los datos.
• Rollup se puede integrar fácilmente en redes blockchain existentes, como Ethereum, lo que permite a los desarrolladores aprovechar sus beneficios sin modificaciones significativas en contratos inteligentes y aplicaciones existentes.
• Rollup aumenta significativamente la capacidad de transacción al procesar un gran número de transacciones fuera de la cadena y enviarlas en lotes a la cadena principal, lo que resulta en un notable aumento en transacciones por segundo (TPS).
• Dado que las transacciones de Rollup se procesan fuera de la cadena, se reduce drásticamente los recursos computacionales y el espacio de almacenamiento requeridos para las transacciones en cadena, lo que disminuye significativamente las tarifas de transacción para el usuario.

Desafíos de Rollup:

• Si los datos fuera de la cadena no están disponibles, los usuarios pueden ser incapaces de verificar las transacciones y recuperar su estado.
• Las transacciones de Rollup deben procesarse en lotes y, finalmente, enviarse a la cadena principal, lo que puede provocar tiempos de liquidación más largos. Esto es especialmente cierto en el caso de op-Rollup, donde hay un período de disputa, lo que hace que los usuarios esperen más tiempo para la confirmación final de la transacción.
• Si bien ZK Rollup proporciona una seguridad más alta y confirmación instantánea, requiere recursos computacionales sustanciales para generar pruebas de conocimiento cero.

Dado que se utiliza Rollup, sus elementos clave de auditoría de seguridad son consistentes con los de la Capa 2 de Ethereum.

Otros (Babilonia)

Además de las soluciones tradicionales de la capa 2 de BTC, han surgido algunos nuevos protocolos de terceros relacionados con el ecosistema BTC, como Babilonia:

Babylon tiene como objetivo transformar 21 millones de BTC en activos de participación descentralizada. A diferencia de otras soluciones de Capa 2 de BTC, Babylon no se centra en escalar la red BTC. En su lugar, es una cadena de bloques única con un protocolo de participación BTC especializado diseñado principalmente para interactuar con cadenas de Prueba de Participación (PoS). El objetivo es apostar BTC para mejorar la seguridad de las cadenas PoS, abordando problemas como los ataques de largo alcance y los riesgos de centralización.

La arquitectura está dividida en tres capas:

• Capa de Bitcoin:Esta es la sólida base de Babilonia, aprovechando la seguridad renombrada de Bitcoin para garantizar que todas las transacciones sean ultra seguras, tal como lo son en la red de Bitcoin.
• Capa de Babilonia:El núcleo de Babilonia, esta cadena de bloques personalizada conecta Bitcoin con varias cadenas PoS. Maneja transacciones, ejecuta contratos inteligentes y garantiza un funcionamiento fluido en todo el ecosistema.
• Capa de cadena PoS:La capa superior consta de múltiples cadenas PoS, cada una seleccionada por sus ventajas únicas. Esta estructura otorga a BabylonChain una notable escalabilidad y flexibilidad, permitiendo a los usuarios beneficiarse de las mejores características de diferentes blockchains PoS.

Babilonia opera firmando bloques finales en la cadena BTC para asegurar las cadenas PoS. Esto extiende esencialmente el protocolo base con una ronda adicional de firmas. Estas firmas en la ronda final +1 tienen una característica única: son Firmas Únicas Extractables (EOTS). El objetivo es integrar checkpoints PoS en la cadena BTC, abordando los problemas de largos períodos de desvinculación y ataques de largo alcance en sistemas PoS.

Ventajas de Babilonia:

• Babilonia acelera el proceso de desvinculación del staking de PoS.
• Al apostar BTC, Babilonia ayuda a aliviar las presiones inflacionarias en la red PoS correspondiente.
• Babylon abre nuevas oportunidades para los titulares de BTC para ganar rendimientos.

Desafíos de Babilonia:

• Las tasas de recompensa por participación y otros factores económicos impactan significativamente el incentivo para la participación de BTC.
• No hay uniformidad en los mecanismos de recompensa en las distintas cadenas de PoS.

El enfoque de seguridad varía dependiendo de la implementación específica de los protocolos de terceros. Para Babilonia, algunos puntos clave de auditoría de seguridad incluyen:

1. Seguridad de Contratos Inteligentes: Los contratos de participación en BTC se implementan a través de scripts UTXO, lo que requiere atención cuidadosa a su seguridad. 2. Seguridad del Algoritmo de Firma: La seguridad del algoritmo de firma utilizado para gestionar la participación en el contrato es crítica, ya que afecta la generación y verificación de firmas. 3. Diseño del Modelo Económico: El modelo económico del protocolo, especialmente en términos de recompensas y penalizaciones, debe ser examinado minuciosamente para garantizar que no conlleve la pérdida de activos de los usuarios.

Apéndice:

Elementos de auditoría general para cadenas públicas & Capa 2

• Desbordamiento de entero:Verificar el desbordamiento y subdesbordamiento de enteros.
• Bucle Infinito:Verifique si las condiciones del bucle en el programa son razonables.
• Recursión Infinita:Asegúrese de que las condiciones de salida para las llamadas recursivas estén correctamente establecidas.
• Condición de carrera:Examine las operaciones de acceso a recursos compartidos bajo condiciones concurrentes.
• Excepciones no controladas:Identificar el código que lanza excepciones que hacen que el programa se cierre inesperadamente.
• División por Cero:Compruebe si hay instancias donde pueda ocurrir la división por cero.
• Conversión de tipo:Asegúrese de que las conversiones de tipo sean precisas y no se pierda información crítica en el proceso.
• Array Fuera de Límites:Asegúrese de que los elementos del array se accedan dentro de límites válidos.
• Vulnerabilidades de deserialización:Verifique problemas durante el proceso de deserialización.
• Implementación de Seguridad de Funcionalidad:Verificar si la implementación de las interfaces RPC es segura y coherente con su diseño funcional.
• Configuración sensible de permisos de interfaz RPC:Asegúrese de que los permisos de acceso para interfaces RPC sensibles estén configurados adecuadamente.
• Mecanismo de Transmisión Encriptado:Verificar el uso de protocolos de transmisión cifrados, como TLS.
• Análisis del Formato de Datos de Solicitud:Verifique el proceso para analizar los formatos de datos de solicitud.
• Ataque de desbloqueo de billetera:Asegúrese de que los fondos no sean robados a través de solicitudes RPC cuando un nodo desbloquea su billetera.
• Seguridad web tradicional:Verifique las siguientes vulnerabilidades: Cross-Site Scripting (XSS), Inyección de plantillas, Vulnerabilidades de componentes de terceros, Contaminación de parámetros HTTP, Inyección SQL, Inyección XXE, Vulnerabilidades de deserialización, Vulnerabilidades SSRF, Inyección de código, Inclusión de archivo local, Inclusión de archivo remoto, Inyección de comandos, etc.
• Mecanismo de autenticación e identificación de nodos de red:Asegúrese de que haya un mecanismo de reconocimiento de identidad de nodo y que no se pueda evitar.
• Envenenamiento de la tabla de enrutamiento:Verifique si la tabla de enrutamiento puede ser manipulada o sobrescrita arbitrariamente.
• Algoritmo de descubrimiento de nodos:Asegúrese de que el algoritmo de descubrimiento de nodos esté equilibrado e impredecible, abordando problemas como desequilibrios en los algoritmos de distancia.
• Auditoría de Ocupación de Conexiones:Asegúrese de que el límite y la gestión de los nodos conectados en la red p2p sean razonables.
• Ataque de Eclipse:Evaluar el costo y el impacto de los ataques de eclipse, brindando análisis cuantitativo si es necesario.
• Ataque de Sybil:Evaluar el mecanismo de consenso de votación y analizar las estrategias para verificar la elegibilidad de voto.
• Ataque de escuchaVerifique que el protocolo de comunicación no filtre información privada.
• Ataque alienígena:Evaluar si los nodos pueden reconocer otros nodos de la misma red blockchain.
• Secuestro de tiempo:Verificar el mecanismo para calcular el tiempo de red en los nodos.
• Ataque de agotamiento de memoria:Verifique las áreas de alto consumo de memoria.
• Ataque de Agotamiento de Disco:Verifique las áreas que involucran almacenamiento de archivos grandes.
• Ataque de estrés del socket:Verificar estrategias que limitan el número de conexiones.
• Ataque de agotamiento del controlador del núcleo:Asegúrese de que los límites en la creación de identificadores del kernel, como los identificadores de archivos, sean razonables.
• Fugas de memoria persistente:Identificar áreas propensas a fugas de memoria.
• Seguridad del algoritmo hash:Asegúrese de que el algoritmo hash sea resistente a colisiones.
• Seguridad del Algoritmo de Firma Digital:Verificar la seguridad del algoritmo de firma y su implementación.
• Seguridad del algoritmo de cifrado:Asegúrese de que el algoritmo de cifrado y su implementación sean seguros.
• Seguridad del Generador de Números Aleatorios:Verifique que los algoritmos críticos de generación de números aleatorios sean razonables.
• Seguridad de la implementación de BFT:Evaluar la seguridad de la implementación del algoritmo de Tolerancia a Fallas Bizantinas (BFT).
• Regla de elección de bifurcación:Verifique la regla de elección de bifurcación para garantizar la seguridad.
• Detección de Centralización:Identificar cualquier centralización excesiva en el diseño del sistema.
• Auditoría del Mecanismo de Incentivos:Evaluar el impacto del mecanismo de incentivos en la seguridad.
• Ataque de Doble Gasto:Verifique si el consenso puede defenderse contra ataques de doble gasto.
• Auditoría de Ataque MEV:Evaluar el impacto del Valor Extraíble Máximo (MEV) en la equidad de la cadena durante el empaque de bloques.
• Auditoría del Proceso de Sincronización de Bloques:Verifique problemas de seguridad durante el proceso de sincronización.
• Auditoría de Análisis de Formato de Bloque:Evaluar las preocupaciones de seguridad durante el análisis de formato de bloque, como errores de análisis que provocan bloqueos.
• Auditoría del Proceso de Generación de Bloques:Revisar la seguridad del proceso de generación de bloques, incluida la construcción de la raíz del árbol de Merkle.
• Auditoría del Proceso de Verificación de Bloques:Verifique los elementos de contenido de las firmas de bloque y si la lógica de verificación es adecuada.
• Auditoría de lógica de confirmación de bloques:Evaluar si el algoritmo de confirmación de bloques y su implementación son razonables.
• Colisión de Hash de Bloque:Verifique cómo se construyen las colisiones de hash de bloque y si el manejo de dichas colisiones es apropiado.
• Límites de recursos de procesamiento de bloques:Verifique si los límites de recursos para la piscina de bloques huérfanos, la computación de verificación y la direccionamiento de disco son razonables.
• Auditoría del Proceso de Sincronización de Transacciones:Revisar problemas de seguridad durante el proceso de sincronización de transacciones.
• Colisión de hash de transacción:Verifique cómo se construyen y manejan las colisiones de hash de transacciones.
• Análisis del formato de transacción:Evaluar las preocupaciones de seguridad durante el análisis de formato de transacciones, como errores de análisis que provocan bloqueos.
• Verificación de legitimidad de transacciones:Verificar los elementos de contenido de varias firmas de transacción y si la lógica de verificación es suficiente.
• Límites de recursos de procesamiento de transacciones:Revise si los límites de recursos para la piscina de transacciones, la computación de verificación y la dirección de disco son razonables.
• Ataque de maleabilidad de transacción:Evaluar si las transacciones pueden alterar los campos internos (por ejemplo, ScriptSig) para cambiar el hash de la transacción sin afectar su validez.
• Auditoría de Ataque de Reproducción de Transacciones:Verifique la detección del sistema de ataques de repetición de transacciones.
• Verificación de Código Byte de Contrato Inteligente:Revisar la seguridad del proceso de verificación de contratos de la máquina virtual, como la comprobación de desbordamientos de enteros y bucles infinitos.
• Ejecución de bytecode de contrato inteligente:Evaluar las preocupaciones de seguridad durante la ejecución de bytecode por la máquina virtual, como desbordamientos de enteros y bucles infinitos.
• Modelo de gas:Asegúrese de que las tarifas de procesamiento de transacciones/ejecución de contratos para cada operación atómica sean proporcionales al consumo de recursos.
• Integridad del registro:Asegúrese de que la información crítica se registre en los registros.
• Seguridad del registro:Verifique si el procesamiento de registros introduce problemas de seguridad, como desbordamientos de enteros.
• Registros que contienen información sensible:Asegúrate de que los registros no contengan claves u otra información privada.
• Almacenamiento de registros:Verifique si el registro excesivo conduce al consumo de recursos en los nodos.
• Seguridad de la cadena de suministro de código de nodo:Revise problemas conocidos con todas las bibliotecas de terceros, componentes y versiones de marcos de cadena pública.

Como una de las primeras empresas de seguridad blockchain a nivel mundial especializada en verificación formal, Beosin se enfoca en un ecosistema integral de "seguridad + cumplimiento". La empresa ha establecido sucursales en más de 10 países y regiones en todo el mundo. Sus servicios abarcan productos de cumplimiento blockchain de un solo paso y servicios de seguridad, que incluyen auditorías de seguridad de código antes del lanzamiento de proyectos, monitoreo de riesgos de seguridad en tiempo real e interceptación durante la operación del proyecto, recuperación de activos robados, prevención de lavado de dinero (AML) para activos virtuales y evaluaciones de cumplimiento que cumplen con los requisitos regulatorios locales. Damos la bienvenida a los proyectos con necesidades de auditoría para contactar al equipo de seguridad de Beosin.

Descargo de responsabilidad：

1. Este artículo es una reimpresión de [Beosin], Todos los derechos de autor pertenecen al autor original [Beosin]. Si hay objeciones a esta reimpresión, por favor póngase en contacto con el Gate Learnequipo, y lo manejarán rápidamente.
2. Responsabilidad de exención: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.