Bitcoin (BTC), como la primera criptomoneda del mundo, se ha convertido gradualmente en la piedra angular de los activos digitales y las finanzas descentralizadas desde su aparición en 2009. Sin embargo, a medida que aumenta el número de usuarios y el volumen de transacciones, los problemas de la red BTC se vuelven cada vez más evidentes, principalmente los siguientes:：

• Altas comisiones de transacción: Cuando la red de Bitcoin está congestionada, los usuarios necesitan pagar tarifas más altas para garantizar que las transacciones se confirmen lo más rápido posible.
• Tiempo de confirmación de transacción: La cadena de bloques de Bitcoin genera un nuevo bloque cada 10 minutos en promedio, lo que significa que las transacciones en cadena a menudo necesitan esperar múltiples confirmaciones de bloques antes de considerarse finales.
• Limitaciones de los contratos inteligentes: el lenguaje de script de Bitcoin tiene funciones limitadas y es difícil de implementar contratos inteligentes complejos.

En este artículo, vamos aRed Lightning(Lightning Network), Sidechains, Rollup y otras tecnologías se denominan colectivamente soluciones de expansión de la capa2 de BTC. Mantienen la descentralización y seguridad de la red BTC al tiempo que logran transacciones rápidas y de bajo costo. La introducción de la tecnología de la Capa2 puede mejorar la velocidad de las transacciones y reducir los costos de transacción, optimizar la experiencia del usuario y expandir la capacidad de la red. Proporciona un soporte técnico importante y una dirección innovadora para el futuro desarrollo de BTC.

En la actualidad, Beosin se ha convertido en el socio de seguridad oficial de BTC Layer2, como Merlin Chain., auditado múltiples protocolos ecológicos de BTC, como Bitmap.Games、Surf Protocol、Savmswap、Mineral. En auditorías pasadas, muchas cadenas públicas conocidas han pasado por las auditorías de seguridad de cadenas públicas de Beosin, incluyendo Ronin Network、Clover、Self Chain、Crust Networkwait. Beosin lanza ahora una solución de auditoría para BTC Layer2 para proporcionar servicios de auditoría de seguridad integrales y confiables para todo el ecosistema BTC.

Red de Relámpagos

El concepto más temprano de la Red Lightning se llama “canales de pago”. Su idea de diseño es actualizar continuamente el estado de transacción no confirmada a través de la sustitución de transacciones hasta que finalmente se transmita a la red Bitcoin. Satoshi Nakamoto ya había propuesto la idea de los canales de pago cuando creó Bitcoin en 2009, e incluyó un código preliminar para los canales de pago en Bitcoin 1.0, lo que permitía a los usuarios actualizar el estado de la transacción antes de que fuera confirmada por la red. Sin embargo, no fue hasta la publicación del libro blanco “La Red Lightning de Bitcoin: Pagos Instantáneos escalables fuera de la cadena” que la Red Lightning nació realmente y entró en el ojo público.

Hoy en día, la implementación de los canales de pago y la Red Lightning es muy madura. Hasta ahora, la Red Lightning cuenta con un total de 13,325 nodos, 49,417 canales, y el número total de BTC comprometidos ha alcanzado los 4,975.

https://1ml.com/

En la Red Lightning, es muy importante asegurar la seguridad de los activos del usuario durante el proceso de transferencia. A continuación se explicará cómo opera la Red Lightning y cómo proteger la seguridad de los activos del usuario en función de la escala de los nodos de la red.

Los usuarios de ambas partes envían dos transacciones a la red principal de Bitcoin: una para abrir el canal y otra para cerrar el canal. Se divide aproximadamente en los siguientes tres pasos:

1. Apertura de canal:

En primer lugar, los usuarios de ambas partes prometen Bitcoin a la billetera multi-firma de la Red Lightning en BTC. Una vez que se ha prometido correctamente y se ha bloqueado el Bitcoin, se abre el canal de pago y ambas partes pueden realizar transacciones fuera de la cadena en este canal.

2. Transacciones fuera de la cadena:

Una vez que se abre el canal, todas las transacciones de transferencia entre usuarios se procesarán en la Red Lightning, y no hay límite en la cantidad de estas transacciones fuera de la cadena. Por supuesto, estas transacciones no necesitan ser enviadas inmediatamente a la Bitcoin mainnet, sino que se completan al instante a través del mecanismo fuera de la cadena de la Red Lightning.

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

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

Cuando los usuarios de ambos lados decidan salir del canal, se producirá el asentamiento final del libro mayor. Este proceso garantiza que todos los fondos en el canal estén asignados hasta la fecha. Al mismo tiempo, los usuarios de ambos lados retirarán el saldo posterior al asentamiento de la billetera multi-firma, que refleja la distribución real de fondos cuando se cierra el canal. Finalmente, el canal enviará el estado final de la transacción del libro mayor a la red principal de Bitcoin.

La ventaja de Lightning Network es que:

• Velocidad de transacción aumentada. La Red Lightning permite a los usuarios realizar transacciones fuera de la cadena, lo que significa que las transacciones se pueden completar casi instantáneamente sin esperar el tiempo de confirmación del bloque. Esto puede lograr velocidades de transacción de segundo nivel, mejorando en gran medida la experiencia del usuario.
• Mejora de la privacidad. Las transacciones fuera de la cadena de Lightning Network no necesitan ser registradas públicamente en la cadena principal de Bitcoin, lo que mejora la privacidad de las transacciones. Solo la apertura y el cierre del canal necesitan ser registrados en la cadena principal, por lo que el comportamiento de transacción del usuario no será completamente revelado.
• Soporte para micropagos. La Red Lightning es muy adecuada para procesar pagos pequeños (micropagos), como pagos de contenido, pagos de dispositivos IoT, etc. Las transacciones tradicionales de Bitcoin no son adecuadas para pagos pequeños frecuentes debido a las altas comisiones de manejo, mientras que la Red Lightning resuelve este problema.

Desafíos que enfrenta la Red Lightning：

• problemas de liquidez de la red: la Red Lightning depende de que los Bitcoins estén prebloqueados en canales. Esto significa que los usuarios deben depositar suficientes Bitcoins en su canal de pago con anticipación para poder realizar una transacción. La falta de liquidez puede provocar que los pagos fallen, especialmente en pagos más grandes.
• problema de enrutamiento: Encontrar una ruta eficiente desde un remitente de pago hasta un receptor puede ser un problema complejo, especialmente en redes más grandes. A medida que aumenta el número de nodos y canales de red, también aumenta la dificultad de garantizar la finalización sin problemas de los pagos.
• Problemas de confianza en la custodia de fondos: los nodos pueden estar sujetos a ataques maliciosos y los usuarios deben confiar en que los nodos a los que están conectados no intentarán robar fondos. ¿Pueden los nodos evitar fugas de claves privadas?
• Estándares técnicos e interoperabilidad: Se necesitan estándares técnicos y protocolos consistentes entre diferentes implementaciones de la Red Lightning para garantizar la interoperabilidad. Actualmente, varios equipos de desarrollo están trabajando en diferentes implementaciones de la Red Lightning, lo que puede generar 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 puede ser rastreada o analizada. Además, los operadores de nodos de la red pueden ver las transacciones que pasan por sus nodos, revelando potencialmente cierta información privada.

La seguridad de la Lightning Network afecta directamente a la escalabilidad fuera de la cadena de Bitcoin y a la seguridad de los fondos de los usuarios. Por lo tanto, además de los elementos de auditoría generales de la cadena pública (consulte el apéndice al final de este artículo para obtener más detalles), la Lightning Network también debe prestar atención a los siguientes riesgos importantes de seguridad:

• Congestión de canales: Verifique la exhaustividad del diseño del sistema de Lightning Network y si causará congestión de canales debido a ataques de luto.
• Interferencia de canal: Verifique la seguridad de la estructura del canal de la Red Lightning y si estará sujeta a ataques de interferencia de canal.
• Bloqueo y desbloqueo de activos del canal: Revisar el proceso de bloqueo y desbloqueo de activos en la Lightning Network para asegurar que al abrir o cerrar un canal de pago, la transferencia de fondos dentro y fuera de la cadena sea segura y confiable.
• Actualización de estado y cierre: Evaluar el proceso de actualización de estado y el mecanismo de cierre forzado del canal para garantizar que el estado más reciente pueda ser identificado y ejecutado correctamente cuando ocurran condiciones anormales.
• Contrato de bloqueo de tiempo y bloqueo de hash (HTLC): Evaluar la implementación de HTLC para garantizar que las condiciones de bloqueo de tiempo y bloqueo de hash se puedan ejecutar correctamente para evitar pérdidas de fondos causadas por problemas de ventana de tiempo.
• Dependencia de la marca de tiempo de la cadena de bloques: Evaluar la dependencia de la Red Lightning en la marca de tiempo de la cadena de bloques de Bitcoin para asegurar que el tiempo dentro y fuera de la cadena se pueda coordinar correctamente y prevenir ataques temporales.
• Seguridad del algoritmo de enrutamiento: Verificar la eficiencia y la seguridad del algoritmo de enrutamiento para prevenir la exposición de la privacidad del usuario y los riesgos de manipulación maliciosa del enrutamiento.
• Almacenamiento del canal y recuperación de datos: Verificar el mecanismo de almacenamiento del canal y la estrategia de recuperación de datos para asegurar que el estado del canal pueda ser restaurado en caso de fallo del nodo o desconexión inesperada, evitando la pérdida de fondos.

cadena lateral

A diferencia de la Lightning Network, la cadena lateral es una cadena de bloques independiente que se ejecuta en paralelo a la cadena principal (como la cadena de bloques BTC) e interactúa con la cadena principal a través de anclaje bidireccional (Two-Way Peg). El propósito de la cadena lateral es lograr más funciones y mejorar la escalabilidad sin cambiar el protocolo de la cadena principal.

Como una cadena lateral independiente, la cadena lateral tiene su propio mecanismo de consenso, nodos y reglas de procesamiento de transacciones. Puede adoptar tecnologías y protocolos diferentes de la cadena principal según las necesidades de escenarios de aplicaciones específicas. A través del mecanismo de anclaje bidireccional (2WP), la cadena lateral se comunica con la cadena principal para garantizar que los activos se puedan transferir libre y seguramente entre ambas. El mecanismo de funcionamiento del mecanismo de anclaje bidireccional (2WP) es aproximadamente el siguiente:

1. El usuario bloquea BTC en la cadena principal y la institución de confianza 1 obtiene y utiliza la verificación SPV 2 para asegurarse de si la transacción bloqueada del usuario está confirmada.

2. La institución de confianza emitirá tokens equivalentes a los usuarios en la cadena lateral.

3. Después de las transacciones gratuitas, los usuarios bloquean los tokens restantes en la cadena lateral.

4. Después de verificar la legalidad de la transacción, la institución de confianza desbloquea el BTC en la cadena principal y libera el valor correspondiente de BTC al usuario.

Nota 1: La autoridad de confianza desempeña un papel clave en el mecanismo de anclaje bidireccional y es responsable de gestionar el bloqueo y la liberación de activos. Estas instituciones deben tener un alto grado de credibilidad y capacidades técnicas para garantizar la seguridad de los activos de los usuarios.

Nota 2: Verificación SPV Permite a los nodos verificar la validez de transacciones específicas sin descargar toda la cadena de bloques. Los nodos SPV solo necesitan descargar el encabezado del bloque y verificar si la transacción está incluida en el bloque a través del árbol Merkle.

Proyectos representativos de cadenas laterales:

CKB（Nervos Network）

Nervos Network es un ecosistema de blockchain público de código abierto que tiene como objetivo aprovechar las ventajas de seguridad y descentralización del mecanismo de consenso POW de BTC, al tiempo que introduce un modelo UTXO más escalable y flexible para procesar transacciones. Su núcleo es Common Knowledge Base (CKB), que es una cadena de bloques de Capa 1 construida sobre RISC-V y usa PoW (Prueba de Trabajo) como consenso. Expande el modelo UTXO en un modelo de Celda, lo que le permite almacenar cualquier dato y admitir la escritura de scripts en cualquier lenguaje para ejecutar en la cadena como un contrato inteligente.

Stacks

Stacks conecta cada bloque de Stacks al bloque de Bitcoin a través de su mecanismo PoX (Proof of Transfer). Para desarrollar contratos inteligentes, Stacks diseñó el lenguaje de programación especializado Clarity. En Clarity, la función get-burn-block-info? permite pasar la altura del bloque de Bitcoin y obtener el hash del encabezado del bloque. Al mismo tiempo, la palabra clave burn-block-height puede obtener la altura actual del bloque de la cadena de Bitcoin. Estas dos 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 sirvan como desencadenantes de contrato. Al automatizar la ejecución de estos contratos inteligentes, Stacks extiende las capacidades de Bitcoin.

Para un análisis detallado de Stacks, puedes leer el artículo de investigación anterior de Beosin: "¿Qué son los Stacks? ¿Qué desafíos puede enfrentar la red de capa 2 de BTC, Stacks?》

La ventaja de las cadenas laterales es que:

• Las cadenas laterales pueden utilizar diferentes tecnologías y protocolos para llevar a cabo diversos experimentos e innovaciones sin afectar la estabilidad y seguridad de la cadena principal.
• Las side chains pueden introducir funciones que la main chain no tiene, como contratos inteligentes, protección de la privacidad, emisión de tokens, etc., para enriquecer los escenarios de aplicación del ecosistema de la cadena de bloques.

Desafíos que enfrentan las sidechains：

• La cadena lateral tiene un mecanismo de consenso independiente, que puede no ser tan seguro como la cadena principal de BTC. Si el mecanismo de consenso de la cadena lateral es débil o tiene lagunas, puede dar lugar a ataques del 51 % u otras formas de ataques, lo que afectaría la seguridad de los activos del usuario. La seguridad de la cadena principal de BTC depende de su enorme potencia informática y de su amplia distribución de nodos, mientras que las cadenas laterales pueden no cumplir con los mismos estándares de seguridad.
• La implementación del mecanismo de anclaje bidireccional requiere algoritmos y protocolos de encriptación complejos. Si hay lagunas en ellos, puede causar problemas con la transferencia de activos entre la cadena principal y la cadena lateral, e incluso puede llevar a la pérdida o robo de activos.
• Para encontrar un equilibrio entre la velocidad y la seguridad, la mayoría de las sidechains tienen un grado de centralización más alto que el de la cadena principal.

Layer2 es un sistema completo de blockchain, por lo que los elementos de auditoría generales de la cadena pública también se aplican a la cadena lateral. Para más detalles, consulte el apéndice al final de este artículo.

Además, debido a su naturaleza especial, las sidechains también requieren una auditoría adicional:

• Seguridad del protocolo de consenso: Revisar si el protocolo de consenso de la cadena lateral (como PoW, PoS, DPoS) ha sido completamente verificado y probado, y si existen posibles vulnerabilidades o vectores de ataque, como ataques del 51%, ataques a larga distancia, etc.
• Seguridad del nodo de consenso: Evaluar la seguridad de los nodos de consenso, incluyendo la gestión de claves, protección de nodos y copias de seguridad redundantes, para evitar que los nodos sean comprometidos o abusados.
• Bloqueo y liberación de activos: Revisar el mecanismo de anclaje bidireccional de activos entre la cadena lateral y la cadena principal para garantizar que los contratos inteligentes de bloqueo y liberación de activos sean seguros y confiables, evitando el doble gasto, la pérdida de activos o el fallo de bloqueo.
• Verificación cruzada: Verificar la precisión y seguridad de la verificación cruzada, asegurar que el proceso de verificación sea descentralizado e inmutable, y prevenir fallas de verificación o verificaciones maliciosas.
• Auditoría del código del contrato: Auditoría exhaustiva de todos los contratos inteligentes que se ejecutan en la cadena lateral para detectar posibles lagunas o puertas traseras, especialmente la lógica del contrato al manejar operaciones entre cadenas.
• Mecanismo de actualización: Verifique si el mecanismo de actualización de contratos inteligentes es seguro y si existen procesos adecuados de auditoría y consenso comunitario para prevenir actualizaciones maliciosas o manipulación de contratos.
• Comunicación entre nodos: Verifique si el protocolo de comunicación entre nodos de la cadena lateral es seguro y si se utilizan canales cifrados para evitar ataques de intermediarios o fugas de datos.
• Comunicación entre cadenas: Verifique el canal de comunicación entre la cadena lateral y la cadena principal para garantizar la integridad y autenticidad de los datos y evitar que la comunicación sea secuestrada o manipulada.
• Marca de tiempo y tiempo de bloque: Verificar el mecanismo de sincronización de tiempo de la cadena lateral para garantizar la consistencia y precisión del tiempo de generación de bloques y prevenir ataques o retrocesos de bloques causados por diferencias de tiempo.
• Seguridad de gobernanza en la cadena: revisar el mecanismo de gobernanza de la cadena lateral para garantizar la transparencia y seguridad de los procesos de votación, propuesta y toma de decisiones, y prevenir el control malicioso o los ataques.
• Auditoría económica del token: Verifique el modelo económico del token de la cadena lateral, incluida la asignación de tokens, el mecanismo de incentivos y el modelo de inflación, para garantizar que los incentivos económicos no conduzcan a comportamientos maliciosos o inestabilidad del sistema.
• Mecanismo de tarifas: Verifique el mecanismo de tarifas de transacción de la cadena lateral para garantizar que coincida con las necesidades de los usuarios de la cadena principal y la cadena lateral para evitar la manipulación de tarifas o congestión de la red.
• Seguridad de activos: audite el mecanismo de gestión de activos en la cadena para asegurar que el proceso de almacenamiento, transferencia y destrucción de activos sea seguro y confiable, y no haya riesgo de acceso no autorizado o robo.
• Gestión de claves: Verifique la política de gestión de claves de la cadena lateral para garantizar la seguridad y el control de acceso de la clave privada y prevenir la filtración o robo de la clave.

Rollup

Rollup es una solución de escalabilidad de Capa 2 diseñada para mejorar el rendimiento y la eficiencia de las transacciones en blockchain. Reduce significativamente la carga en la cadena principal al empaquetar ("Rollup") un gran número de transacciones y procesarlas fuera de la cadena, solo enviando los resultados finales a la cadena principal.

Rollup se divide principalmente en zk-Rollup y op-Rollup. Pero a diferencia de ETH, debido a la incompletitud de Turing de BTC, es imposible utilizar contratos en BTC para la verificación de pruebas de conocimiento cero. Las soluciones tradicionales de zk-Rollup no se pueden implementar en BTC. Entonces, ¿cómo implementar BTC Layer2 utilizando zk-Rollup? A continuación, tomemos el proyecto de la red B² como ejemplo:

Para completar la verificación de prueba de conocimiento cero en BTC, B² Network creó el script Taproot, que combina la verificación de prueba de conocimiento cero de zk-Rollup y el desafío de incentivo de op-Rollup. Su mecanismo de funcionamiento es aproximadamente el siguiente:

1. B² Network primero agrupa todas las transacciones iniciadas por los usuarios.

2. Después de usar el clasificador para ordenar las transacciones de Rollup, guarda las transacciones de Rollup usando almacenamiento descentralizado y entrégaselos a zkEVM para su procesamiento al mismo tiempo.

3. Después de que zkEVM sincronice el estado de la cadena BTC, procesa transacciones como la ejecución de contratos, fusiona y empaqueta los resultados y los envía al agregador.

4. Prover genera una prueba de conocimiento cero y la envía al agregador. El agregador agrega las transacciones y envía la prueba a los nodos B².

5. B² Nodes realiza la verificación de la prueba de conocimiento cero y crea scripts Taproot basados en los datos Rollup en el almacenamiento descentralizado.

6. Taproot es un UTXO con un valor de 1 satoshi. La Inscripción B² en su estructura de datos almacena todos los datos de Rollup, y Tapleaf almacena todos los datos de verificación. Después de pasar el mecanismo de desafío de incentivos, se enviará a BTC como un compromiso verificado basado en la prueba zk.

La ventaja de Rollup es que:

• RollupHereda las características de seguridad y descentralización de la cadena principal. Al enviar regularmente datos de transacciones y estado a la cadena principal, se garantiza la integridad y transparencia de los datos.
• Rollup se puede integrar perfectamente en redes blockchain existentes como Ethereum, lo que permite a los desarrolladores aprovechar fácilmente sus beneficios sin modificar significativamente los contratos inteligentes y aplicaciones existentes.
• Al procesar una gran cantidad de transacciones fuera de la cadena y empaquetarlas en un lote para su envío a la cadena principal, Rollup mejora en gran medida las capacidades de procesamiento de transacciones y aumenta significativamente el número de transacciones por segundo (TPS).
• Las transacciones de Rollup solo necesitan ser procesadas fuera de la cadena, lo que reduce en gran medida los recursos informáticos y el espacio de almacenamiento necesarios para las transacciones en cadena, lo que reduce significativamente las tarifas de transacción para los usuarios.

Desafíos enfrentados por Rollup:

• Si los datos fuera de la cadena no están disponibles, es posible que los usuarios no puedan verificar las transacciones y restaurar el estado.
• Las transacciones Rollup deben procesarse en lotes y finalmente enviarse a la cadena principal, lo que puede resultar en tiempos de liquidación más largos. Especialmente en op-Rollup, existe un período de disputa y los usuarios pueden tener que esperar mucho tiempo antes de que la transacción se confirme finalmente.
• Aunque ZK Rollup proporciona una seguridad más alta y confirmaciones instantáneas, sus requisitos de computación y almacenamiento son altos, y la generación de pruebas de conocimiento cero requiere una gran cantidad de recursos informáticos.

Dado que la solución adoptada es Rollup, sus elementos clave de auditoría de seguridad son básicamente los mismos que los de ETH Layer2.

Otros (Babilonia)

Además de la tradicional capa 2 de BTC, también hay algunos protocolos de terceros de nuevo concepto relacionados con el ecosistema BTC recientemente, como Babylon:

El objetivo de Babilonia es convertir 21 millones de BTC en activos de participación descentralizada. A diferencia de otras capas 2 de BTC, Babilonia no expande la cadena BTC. Es una cadena única en sí misma, con un protocolo de hipoteca BTC especial. El propósito principal es conectarse con la cadena PoS. Hipotecar BTC para proporcionar una seguridad más fuerte para la cadena PoS y resolver el riesgo de ataques desde el extremo remoto de la cadena y la pregunta centralizada.

La arquitectura se divide en tres capas:

Capa de Bitcoin: Esta es la sólida base de Babilonia, aprovechando la seguridad bien conocida de Bitcoin para garantizar que todas las transacciones sean súper seguras, al igual que en la red de Bitcoin.

Capa babilónica: En el corazón de Babilonia se encuentra la capa babilónica, una cadena de bloques personalizada que conecta Bitcoin con varias cadenas de Prueba de Participación (PoS). Procesa transacciones, ejecuta contratos inteligentes y garantiza que todo funcione sin problemas en todo el ecosistema.

Capa de cadena PoS: La capa superior está compuesta por múltiples cadenas PoS, cada una seleccionada por sus ventajas únicas. Esto le da a BabylonChain una escalabilidad y flexibilidad increíbles, lo que permite a los usuarios disfrutar de las mejores características de diferentes blockchains PoS.

La forma en que funciona es asegurar la cadena PoS utilizando bloques finales firmados en la cadena BTC. Esto extiende esencialmente el protocolo base con rondas de firma adicionales. Estas firmas en la ronda final +1 tienen una característica única: son Firmas Únicas Extraíbles (EOTS, por sus siglas en inglés). El propósito es integrar puntos de control PoS en BTC para resolver el largo período de desvinculación y los problemas de ataque remoto de PoS.

La ventaja de Babilonia es que:

• Hacer el período de desvinculación de PoS más rápido
• Dado que BTC está garantizado, el precio está vinculado a BTC, lo que puede reducir la presión inflacionaria en la red correspondiente de PoS.
• Abre nuevas oportunidades para ganar BTC

Desafíos que enfrenta Babilonia:

• Diseños económicos como la tasa de retorno de apuestas tienen un mayor impacto en el entusiasmo por las apuestas de BTC
• Falta de disposiciones de consistencia de recompensa entre las cadenas de PoS

Los protocolos de terceros tienen diferentes puntos de seguridad dependiendo de su implementación. Tomando Babilonia como ejemplo, algunos elementos de auditoría de seguridad que necesitan atención son los siguientes:

1. Seguridad del contrato inteligente: El contrato de garantía en BTC se implementa a través de un script UTXO, y su seguridad debe ser tomada en cuenta.

2. Seguridad del algoritmo de firma: Las firmas se utilizan en el contrato para gestionar las promesas de los usuarios, y la seguridad de su algoritmo está relacionada con la generación y verificación de las firmas.

3. Diseño del modelo económico del protocolo: Si el modelo económico del protocolo está razonablemente establecido en términos de recompensas y penalizaciones, y si conducirá a la pérdida de activos del usuario.

apéndice:

Elementos generales de auditoría de la cadena pública y Layer2

• Desbordamiento de enteros: Verificar el desbordamiento y el subdesbordamiento de enteros
• Bucle infinito: Compruebe si las condiciones de juicio del bucle del programa son razonables
• Llamada recursiva infinita: Compruebe si la condición de salida de la llamada recursiva del programa es razonable
• Condiciones de carrera: Verificar operaciones de acceso a recursos compartidos en condiciones concurrentes
• Crash anormal: Verificar el código que permite la salida activa del programa al lanzar una excepción.
• Vulnerabilidad de división por 0: Verifique si hay división por 0
• Conversión de tipo: Verifique si la conversión de tipo es correcta y si se pierde información importante durante el proceso de conversión
• Índice fuera de límites: Verifique si se accede a un elemento más allá de los límites del array
• Vulnerabilidad de deserialización: compruebe si hay algún problema durante el proceso de deserialización
• Seguridad en la implementación funcional: Verificar si existen riesgos de seguridad en cada implementación de interfaz RPC y si es consistente con la función de la interfaz RPC.
• Se puede diseñar para que coincida
• Si la configuración de permisos de la interfaz RPC sensible es razonable: Verifique la configuración de permisos de acceso de la interfaz RPC sensible
• Mecanismo de transmisión cifrado: Verificar si se utiliza un protocolo de transmisión cifrado, como TLS, etc.
• Análisis del formato de datos de solicitud: Verifique el proceso de análisis de formato de los datos de la solicitud
• Ataque de desbloqueo de billetera: Cuando un nodo desbloquea su billetera, RPC le solicita que robe fondos.
• Seguridad Web tradicional: Verifique las siguientes vulnerabilidades: scripting entre sitios (XSS) / inyección de plantillas
• Vulnerabilidades de componentes de terceros / Contaminación de parámetros HTTP / Inyección SQL / Inyección de entidad XXE deserialización
• vulnerabilidades/vulnerabilidades SSRF/inyección de código/inclusión de archivo local/inclusión de archivo remoto/inyección de ejecución de comandos y otras vulnerabilidades tradicionales
• Mecanismo de autenticación e identificación de la identidad del nodo de red: Verifique si hay un mecanismo de identificación de nodo y si se puede pasar por alto el mecanismo de identificación del nodo.
• Contaminación de la tabla de enrutamiento: Compruebe si la tabla de enrutamiento puede ser insertada aleatoriamente o sobrescrita con datos.
• Algoritmo de descubrimiento de nodos: Verifique si el algoritmo de descubrimiento de nodos es equilibrado e impredecible, como el algoritmo de distancia desequilibrada y otros problemas
• Auditoría de ocupación del número de conexiones: Verifique si el límite y la gestión del número de nodos de conexión de red p2p son razonables
• Ataque de eclipse: Evaluar el costo y el daño de un ataque de eclipse y proporcionar un análisis cuantitativo si es necesario
• Ataque Sybil: Evalúe el mecanismo de consenso de votación y analice la estrategia de verificación de calificación de votación
• Ataque de escucha: Verificación de los protocolos de comunicación en busca de filtraciones de privacidad
• Ataque alienígena: Evalúa si el nodo puede identificar nodos de cadena similares
• Secuestro de tiempo: Verificación del mecanismo de cálculo del tiempo de red de un nodo
• Ataque de agotamiento de memoria: comprobación de lugares de gran consumo de memoria
• Ataque de agotamiento del disco duro: compruebe dónde se almacenan los archivos grandes
• Ataque de presión de socket: verifica la política de límite en el número de conexiones
• Ataque de agotamiento de manejadores de kernel: Verifique los límites de creación de manejadores de kernel, como los manejadores de archivos, etc.
• Fugas de memoria persistentes: Verificar fugas de memoria
• Seguridad del algoritmo hash: Comprobación de la resistencia a colisiones de un algoritmo hash
• Seguridad del algoritmo de firma digital: Verifique la seguridad del algoritmo de firma y la seguridad de la implementación del algoritmo
• Seguridad del algoritmo de cifrado: Verificar la seguridad del algoritmo de cifrado, seguridad de la implementación del algoritmo
• Seguridad del generador de números aleatorios: Verificación de si los algoritmos críticos de generación de números aleatorios son sólidos
• Seguridad de la implementación de BFT: Evaluando la seguridad de la implementación del algoritmo BFT
• Reglas de elección de bifurcación: Verificar las reglas de elección de bifurcación para garantizar la seguridad
• Detección de centralización: identificar si hay una centralización excesiva en el diseño del sistema
• Auditoría de incentivos: Evaluar el impacto de los incentivos en la seguridad
• Ataque de doble gasto: compruebe si el consenso puede defenderse contra un ataque de doble gasto.
• Auditoría de ataque MEV: Compruebe el impacto de MEV de los nodos de empaquetado de bloques en la equidad de la cadena
• Auditoría del proceso de sincronización de bloques: compruebe los problemas de seguridad durante el proceso de sincronización
• Auditoría del proceso de análisis del formato de bloque: Verificar problemas de seguridad en el proceso de análisis del formato, como errores de análisis que provocan bloqueos
• Auditoría del proceso de generación de bloques: Compruebe los problemas de seguridad durante el proceso de generación de bloques, incluido si el método de construcción de la raíz del árbol de Merkle es razonable
• Auditoría del proceso de verificación de bloques: Verificar si los elementos de contenido de firma del bloque y la lógica de verificación son suficientes.
• Auditoría de lógica de confirmación de bloque: Verificar si el algoritmo de confirmación de bloque y su implementación son razonables
• Colisión de hash de bloque: Verifique el método de construcción de la colisión de hash de bloque y si el manejo de la colisión es razonable.
• Límites de recursos de procesamiento de bloques: Verifique si los límites de recursos como el grupo de bloques huérfanos, el cálculo de verificación, la dirección del disco duro, etc. son razonables.
• Auditoría del proceso de sincronización de transacciones: Verificar problemas de seguridad durante el proceso de sincronización
• Colisión de hash de transacción: Verifique el método de construcción de colisión de hash de transacción y el procesamiento de la colisión
• Análisis de formato de transacción: compruebe los problemas de seguridad durante el proceso de análisis de formato, como los errores de análisis que provocan bloqueos
• Verificación de legalidad de transacciones: Verificar si cada tipo de elemento de contenido de firma de transacción y lógica de verificación son suficientes.
• Límites de recursos de procesamiento de transacciones: Verifique si los límites de recursos, como las piscinas de transacciones, los cálculos de verificación, la dirección del disco duro, etc., son razonables.
• Ataque de maleabilidad de transacciones: ¿Puede una transacción cambiar campos internos (como ScriptSig) para cambiar el hash de la transacción sin afectar la validez de la transacción?
• Auditoría de ataque de repetición de transacción: Verificación del sistema de detección de repetición de transacción
• Verificación del bytecode del contrato: Verificar los problemas de seguridad del proceso de verificación de la máquina virtual del contrato, como el desbordamiento de enteros, bucle infinito, etc.
• Ejecución de código de bytes de contrato: verifique los problemas de seguridad en el proceso de ejecución de código de bytes de la máquina virtual, como desbordamiento de enteros, bucle infinito, etcétera.
• Modelo de gas: Compruebe si las tarifas de manejo correspondientes a cada operación atómica de procesamiento de transacciones/ejecución de contratos son proporcionales al consumo de recursos
• Integridad del registro: Verificar si se registra la información clave
• Seguridad de los registros de registro: compruebe si hay problemas de seguridad causados por un manejo incorrecto durante el procesamiento de registros, como desbordamiento de enteros, etcétera.
• El registro contiene información privada: compruebe si el registro contiene información privada, como claves
• Almacenamiento de registros: Verificar si el registro registra demasiado contenido, lo que causa un consumo excesivo de recursos del nodo
• Seguridad de la cadena de suministro del código del nodo: Verifique los problemas conocidos de todas las bibliotecas de terceros, componentes y versiones correspondientes del marco de la cadena pública

Beosin es una de las primeras compañías de seguridad blockchain en el mundo en realizar verificación formal. Centrándose en el negocio ecológico completo de “seguridad + cumplimiento”, ha establecido sucursales en más de 10 países y regiones de todo el mundo. Su negocio cubre auditorías de seguridad de código antes de que el proyecto se publique, monitoreo y bloqueo de riesgos de seguridad durante la operación del proyecto, recuperación de robos, productos de cumplimiento de blockchain de “una sola parada” + servicios de seguridad como el lavado de dinero (AML) de activos virtuales y evaluaciones de cumplimiento que cumplen con los requisitos regulatorios locales. Las partes del proyecto con necesidades de auditoría pueden comunicarse con el equipo de seguridad de Beosin.

Descargo de responsabilidad:

1. Este artículo es reimpreso de [Beosin]. Todos los derechos de autor pertenecen al autor original [Beosin]. Si hay objeciones a esta reimpresión, por favor contacte a la Gate Learn equipo, y lo manejarán con prontitud.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son exclusivamente los 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 lo contrario, está prohibido copiar, distribuir o plagiar los artículos traducidos.