Los tres atributos principales de la cadena de bloques son la descentralización, la seguridad y la escalabilidad. Según la teoría del trilema de la cadena de bloques, una arquitectura de cadena de bloques solo puede implementar dos de estos. Ethereum fue diseñado teniendo en cuenta la descentralización y la seguridad, por lo tanto, tiene un rendimiento deficiente en términos de escalabilidad. Actualmente, Ethereum procesa más de 1 millón de transacciones al día, lo que puede provocar altas tarifas de transacción y aumentar la necesidad de soluciones de escalado de Ethereum.

Existen varios tipos diferentes de soluciones de escalado de Ethereum, cada una con sus propias compensaciones y modelos de seguridad, incluyendo la fragmentación de Capa 1, los canales de estado de Capa 2, Plasma, las sidechains, los Rollups y Validium. Debido a que la tecnología de fragmentación es lenta en evolucionar y compleja de implementar, y las sidechains y Validium no pueden heredar la seguridad y disponibilidad de datos de Ethereum. En resumen, el ecosistema de Ethereum ahora principalmente utiliza la solución de escalado Rollups.

Hasta ahora, Beosin se ha convertido en un socio de seguridad de ETH Layer2, como Manta Netowork y StarkNet. En la auditoría pasada, varias blockchains bien conocidas han pasado la auditoría de seguridad de cadena de Beosin, incluyendo Ronin Network, Manta Network, Merlin Chain, Clover, Self Chain, Crust Network, etc. Beosin ahora lanza una solución de auditoría para ETH Layer2 para proporcionar servicios de auditoría de seguridad integrales para el ecosistema de ETH Layer2.

ETH Layer2 utiliza Rollups para empaquetar cientos de transacciones en una sola presentación a la red principal de Ethereum, de esta manera, las tarifas de transacción se dividirán entre todos los usuarios de Rollup, reduciendo las tarifas por usuario. Los datos de transacción en los Rollups se envían a la Capa1, pero las ejecuciones se llevan a cabo de forma independiente por los Rollups. Al enviar los datos de transacción a la Capa1, los Rollups pueden heredar la seguridad de Ethereum, ya que una vez que los datos se cargan en la Capa1, revertir las transacciones de Rollups requiere que los datos se reviertan en la Capa1.

Actualmente, los Rollups se pueden implementar de dos maneras principales:

Rollups Optimistas: Utilizan incentivos económicos y teoría de juegos para verificar transacciones, como Arbitrum, Base, OP, Blast, etc.

Zero-Knowledge Rollups: Utilice pruebas de conocimiento cero para seguridad y privacidad, como Scroll, Linea, zkSync, StarkNet, etc.

Rollups optimistas

Introducción

Optimistic Rollups es una forma de escalar Ethereum al mover la computación y el almacenamiento del estado fuera de la cadena. Ejecuta transacciones fuera de la cadena, pero publica los datos de la transacción en la mainnet como calldata o blob.

Optimistic Rollups despliega un contrato inteligente en Ethereum, llamado contrato Rollup, que gestiona el estado del Rollup, realiza un seguimiento de los saldos de los usuarios y maneja los depósitos, retiros y resolución de disputas. Las transacciones se recopilan y resumen fuera de la cadena por un secuenciador y varias transacciones se agrupan en un bloque Rollup que contiene un resumen y una prueba criptográfica del nuevo estado de la cuenta (raíz de Merkle). Luego, el secuenciador compromete el bloque Rollup en la cadena principal proporcionando raíces de Merkle y calldata.

Los Rollups Optimistas se consideran "optimistas" porque asumen que las transacciones fuera de cadena son válidas y no publican pruebas de la validez de los lotes de transacciones enviados en cadena. Los Rollups Optimistas, por otro lado, se basan en esquemas de prueba de fraude para detectar casos en los que las transacciones se calculan incorrectamente. Después de enviar un lote de Rollup en Ethereum, hay un período de tiempo (llamado período de desafío) durante el cual cualquier persona puede desafiar los resultados de una transacción de Rollup calculando pruebas de fraude. La prueba de fraude contiene detalles de una transacción en particular que el verificador cree que es fraudulenta.

Como se muestra en la figura a continuación, el período de desafío de la mayoría de los Optimistic Rollups en la actualidad es de 7 días, y el más corto es de 1 día.

Durante el período de desafío, cualquier persona puede desafiar los resultados de la transacción calculando la prueba de fraude. Si la transacción es inválida, el bloque Rollup es revocado, el desafiante es recompensado y el secuenciador es castigado.

Si el lote de Rollup queda sin impugnar después del período de desafío (es decir, todas las transacciones se han ejecutado correctamente), se considera válido y aceptado en Ethereum. Otros pueden seguir expandiendo bloques de Rollup no confirmados, pero tenga en cuenta que los resultados de la transacción se revertirán si la transacción se ejecuta en base a un error previamente publicado.

Finalmente, el usuario debe enviar una solicitud de retiro al contrato de Rollup para retirar fondos de la Capa 2 a la Capa 1. El contrato verificará que el usuario tenga suficientes fondos en el Rollup y actualizará su saldo en la cadena principal en consecuencia.

Redes líderes de Layer2

1. Arbitrum

Con construcción ecológica y airdrops, Arbitrum se convirtió rápidamente en la red más activa en ETH Layer2, con TVL superior a los $2.7 mil millones. Después del gran airdrop, el equipo de Arbitrum lanzó el programa Arbitrum Orbit: alentando a los desarrolladores a construir Layer3 utilizando tecnologías relacionadas con Arbitrum. Beosin ha completado la auditoría de seguridad de ArbSwap, Arbipad para ayudar al desarrollo de seguridad del ecosistema de Arbitrum.

1. Optimismo

Aunque Optimism es menos activo ecológicamente que Arbitrum, OP Stack, lanzado por Optimism en 2023, ha ganado un amplio reconocimiento en la industria como una solución completa y viable para construir Layer2 modular. Se han construido más de 25 redes Layer2 utilizando OP Stack, incluidos proyectos estrella como Base, Mantle, Manta, OP BNB y Celo. DIPX Finance y Starnet construidos en Optimism han pasado la auditoría de seguridad de Beosin.

1. Base

Base es una red Layer2 basada en OP Stack, que es la segunda más activa en términos de actividad ecológica y TVL, después de Arbitrum. Anteriormente, Beosin ha analizado en detalle la arquitectura de Base y los riesgos de seguridad, y ha auditado Surf Protocol y EDA para ayudar a los propietarios y usuarios del proyecto a evitar riesgos de seguridad.

1. Blast

Al final de su competencia de desarrolladores “Big Bang”, Blast ha visto cómo su TVL se disparaba a más de $2 mil millones, tomando su lugar en el circuito Layer2. Beosin analizó la seguridad de la red de Blast antes de su lanzamiento en la mainnet. Debido a que Blast no implementa pruebas de fraude, los activos se mantienen en una billetera multi-firma, no en un puente Rollup, lo que tiene un alto grado de riesgo de centralización. Beosin ha auditado varios proyectos ecológicos de Blast como Wand Protocol, Zest, Kalax.

Análisis de arquitectura

OP Stack, un marco maduro para Optimistic Rollups, básicamente descompone el complejo proceso de construcción de cadenas de Optimistic Rollups en un proceso simplificado al proporcionar un conjunto completo de componentes de software, herramientas y marcos. Aquí tomamos el marco Op stack como ejemplo para analizar la arquitectura típica de Optimism Rollups.

● Nodo de ejecución: Op-geth es un cliente de ejecución extendido para Ethereum que maneja funciones específicas de Layer2, como recibir depósitos de tokens de Layer1. Esta capa define todas las funciones responsables de realizar variaciones de estado. Aquí, las transiciones de estado se desencadenan en función de la entrada recibida de los nodos resumen (secuencias y validadores) a través de la API del motor.

● Nodo de Rollup: incluye el secuenciador y el validador. El recolector es responsable de agrupar las transacciones procesadas de la capa 2 y publicarlas en la Capa 1. El secuenciador define cómo se recopilan y publican las transacciones en la cadena de Capa 2. El validador/validador verifica la validez de la transacción agrupada y presenta pruebas si se detecta algún fraude.

● Prueba de fraude: Cannon es una versión mejorada de Geth y es responsable de ejecutar EVM durante la fase de detección y prueba de fraude. Esencialmente, es un motor de disputas en cadena que se coordina con secuentes y validadores a través de APIs para demostrar transacciones falsas.

● Compromiso por lotes: Los secuenciadores procesan en lotes todas las transacciones procesadas de una vez, verificadas por los verificadores, y los secuenciadores envían las transacciones procesadas por lotes a Layer1.

● Contratos puente: Desplegados en Ethereum y Layer2, permitiendo a los usuarios enviar mensajes y transferir activos entre Layer1 y Layer2.

Bajo la arquitectura técnica de Optimistic Rollup, es esencial garantizar la seguridad de los activos de los usuarios a medida que se mueven entre L1 y L2. A continuación se detalla cómo los usuarios pueden acceder a los activos entre las dos capas y cómo el sistema mantiene la integridad y seguridad de estas transacciones.

● Transferencia de activos a Rollup: Los usuarios depositan fondos en el contrato de puente de cadena de Rollup en Layer1. El contrato de puente de cadena transmite la transacción a Layer2, donde se crea la misma cantidad de activos y se envía a una dirección seleccionada por el usuario en Optimistic Rollup.

Las transacciones generadas por el usuario, como los depósitos de la Capa1 a la Capa2, suelen estar en cola hasta que el segregador las vuelva a enviar al contrato Rollup. Sin embargo, para mantener la resistencia a la censura, Optimistic Rollup permite a los usuarios enviar transacciones directamente a contratos Rollup en cadena si los retrasos de transacción superan el tiempo máximo permitido.

● Retirar activos de Rollup: Debido al mecanismo de prueba de fraude, retirar dinero de Optimistic Rollup a Ethereum es más complicado. Si un usuario inicia una transacción de Capa2 a Capa1 para retirar fondos gestionados en Capa1, necesita esperar al final del período de desafío, que suele durar alrededor de 7 días.

Cuando el usuario inicia una solicitud de retiro en Rollup, la transacción se incluye en el siguiente lote y los activos del usuario en Rollup son destruidos. Una vez que el lote se publica en Ethereum, los usuarios pueden calcular una prueba de Merkle para verificar que su transacción de salida está incluida en el bloque. El siguiente paso es esperar a que finalice el período de demora para completar la transacción en Layer1 y retirar los fondos a la mainnet.

Para evitar esperar una semana antes de retirar dinero de Ethereum, los usuarios de Optimistic Rollup pueden solicitar un adelanto a un proveedor de liquidez (LP), que asume la propiedad de retiros pendientes y paga los fondos al usuario en Layer1 a cambio de una tarifa. Los proveedores de liquidez pueden verificar la validez de las solicitudes de retiro de los usuarios revisando los datos on-chain ellos mismos antes de liberar fondos. De esta manera, pueden asegurarse de que la transacción eventualmente será confirmada, logrando la certeza de confianza.

Elementos de auditoría

Layer2 es un sistema completo de blockchain, por lo que la auditoría común de las cadenas públicas también se aplica a Optimistic Rollup, como se detalla en el apéndice al final de este artículo.

Además, debido a su naturaleza especial, Optimistic Rollup requiere una serie de auditorías adicionales:

● Prueba de disponibilidad de datos: Asegurar que los datos de transacción de Layer2 estén disponibles en Layer1 para evitar pérdida de datos.

● Mecanismo de sincronización de datos: Verificar si el mecanismo de sincronización de datos entre Layer1 y Layer2 es sólido y puede manejar situaciones anormales como la partición de la red.

● Contrato de Prueba de Fraude: Verificar que el contrato de prueba de fraude esté implementado correctamente.

● Mecanismo de período de desafío: Verificar si la duración del período de desafío es razonable y si la prueba de fraude puede completarse dentro del tiempo especificado.

● Proceso de envío de pruebas de fraude: Verifique que el proceso para enviar pruebas de fraude sea seguro.

● Proceso de depósito y retiro: Verifique el proceso de depósito y retiro de Layer1 a Layer2 y de Layer2 a Layer1 para garantizar que el proceso sea seguro.

● Acuñación y destrucción de activos: Verificar la lógica de creación y destrucción del activo en Layer2 para asegurar la correspondencia correcta con el activo de Layer1.

● Mecanismo de proveedor de liquidez: Si existe un mecanismo de proveedor de liquidez (LP), es necesario examinar el proceso operativo del LP y su seguridad.

Zero-Knowledge Rollups

Introducción

Zero-Knowledge (ZK) Rollup es una solución de escalado basada en Layer2 que utiliza pruebas de conocimiento cero. Principalmente realiza cálculos complejos y generación de pruebas fuera de la cadena, verifica las pruebas en la cadena y almacena parte de los datos para garantizar la disponibilidad de los mismos.

ZK Rollup es una “solución de escalado” híbrida que es un protocolo fuera de la cadena que se ejecuta de forma independiente pero obtiene seguridad de Ethereum. Específicamente, la red de Ethereum hace cumplir la validez de las actualizaciones de estado en los ZK Rollups y garantiza la disponibilidad de los datos de fondo cada vez que se actualiza el estado de Rollup. El estado de Rollup es mantenido por contratos inteligentes desplegados en la red de Ethereum. Para actualizar este estado, el nodo de ZK Rollups debe enviar una prueba de validez para su verificación. Una prueba de validez es una garantía criptográfica de que un cambio propuesto en el estado es realmente el resultado de la ejecución de un lote dado de transacciones. Esto significa que ZK Rollups solo necesita proporcionar una prueba de validez para finalizar transacciones en Ethereum, sin tener que publicar todos los datos de transacción.

No hay retraso en la transferencia de fondos de ZK Rollups a Ethereum, ya que la transacción de salida se ejecuta una vez que el contrato de ZK Rollups ha verificado la prueba de validez. En cambio, retirar fondos de Optimistic Rollups crea retrasos porque cualquier persona puede utilizar una prueba de fraude para desafiar una transacción de salida.

Redes líderes de Capa 2

1. zkSync

zkSync, una solución de capa 2 lanzada hace cinco años por el equipo de Matter Labs, utiliza la tecnología de prueba de conocimiento cero para permitir una verificación de transacciones eficiente y ha recaudado más de $200 millones. zkSync es una de las redes de Capa 2 más activas ecológicamente que utiliza ZK Rollups, y zkSync también es controvertido. Beosin realizó previamente una auditoría de su proyecto líder de DeFi, SyncSwap, que cubría la calidad del código, la lógica del contrato, la seguridad, el modelo operativo y más.

1. StarkNet

StarkNet utiliza ZK-STARK para construir Layer2 y aumentar la velocidad de las transacciones y reducir las comisiones de transacción. StarkNet cuenta con una máquina virtual nativa (Cairo VM) y un lenguaje de desarrollo llamado Cairo para ayudar a los desarrolladores a escribir contratos inteligentes de forma más segura y sencilla. Beosin se ha convertido en socio oficial de seguridad de StarkNet, completando auditorías de seguridad para Option Dance y Reddio. El 13 de agosto de 2024, Reddio cerró una ronda de financiación inicial liderada por Paradigm para construir una red de alto rendimiento paralela EVM Layer2.

1. Desplazarse

Scroll se escala mediante tecnología de prueba de conocimiento cero, y el hardware acelera la generación y verificación de pruebas de conocimiento cero, con el objetivo de lograr la compatibilidad de nivel de bytecode EVM. Esto significa que los desarrolladores pueden usar directamente Solidity y herramientas de desarrollo relacionadas con Ethereum para construir contratos inteligentes en ETH.

Análisis de la arquitectura

Los marcos comunes para ZK Rollups incluyen contratos Rollup y Bridge, recolectores, agregadores, Repeaters y redes Roller que generan pruebas de conocimiento cero. La arquitectura específica se muestra en la siguiente figura:

● Contrato Rollup y contrato Puente:

El contrato Rollup es responsable de proporcionar la disponibilidad de datos para las transacciones de Rollup, verificar la prueba de validez zkEVM y permitir a los usuarios transferir activos entre Ethereum y Rollup. Recibe la raíz del estado de la Capa 2 y el bloque del recolector, la raíz del estado se guarda en el estado de Ethereum y los datos del bloque de la capa 2 se guardan como los datos de llamada de Ethereum.

Los contratos de puente se implementan en Ethereum y Layer2, lo que permite a los usuarios enviar mensajes y transferir activos entre Layer1 y Layer2.

● Secuenciador: El secuenciador proporciona la interfaz JSON-RPC y acepta transacciones de Capa2, recupera periódicamente un lote de transacciones de la memoria temporal para su ejecución, generando nuevos bloques de Capa2 y raíces de estado. Su implementación se basa generalmente en Go-Ethereum (Geth), lo que garantiza la mejor compatibilidad y la más alta seguridad.

● Coordinador: El coordinador es notificado cuando el colador genera un nuevo bloque y recibe una traza de ejecución de ese bloque del colador. Luego, la traza de ejecución se envía a un Roller seleccionado al azar en la red de Rollers, que genera una prueba de validez.

● Relayer: El repetidor monitorea los contratos Rollup y los contratos de puente desplegados en Ethereum y Layer2. Las principales responsabilidades son: 1) Rastrear la disponibilidad de datos y la validación de los bloques Layer2 mediante la monitorización de los contratos Rollup; 2) Monitorizar los eventos de depósito y retiro de la participación en puentes Ethereum y Layer2 y transmitir mensajes al otro extremo.

● Roller Network: Roller en la red de Roller actúa como el probador y es responsable de generar una prueba de validez para ZK Rollup. Se recibe primero una traza de ejecución de bloque del coordinador, se convierte en un testigo de circuito, luego se genera una prueba para cada zkevm utilizando aceleración de hardware y finalmente se utiliza una agregación de pruebas para agregaGate múltiples pruebas en una sola prueba.

Bajo la arquitectura técnica de ZK Rollups, es esencial asegurar la seguridad de los activos de los usuarios durante la transferencia entre L1 y L2. A continuación, se detalla cómo los usuarios pueden acceder a los activos entre las dos capas y cómo el sistema mantiene la integridad y seguridad de estas transacciones.

● Puente de activos en Rollup: Los usuarios ingresan al Rollup mediante la publicación de tokens en un contrato de ZK Rollups implementado en una capa de cadena de red. Esta transacción debe enviarse al contrato acumulativo por parte del proyecto.

Si la cola de depósitos pendientes comienza a llenarse, el operador de ZK Rollups aceptará estas transacciones de depósito y las enviará al contrato Rollup. Una vez que los fondos se depositen en Rollup, el usuario puede comenzar el procesamiento de transacciones.

Los usuarios pueden verificar el saldo en Rollup mediante la hash de su cuenta, enviando el valor de hash al contrato de Rollup y proporcionando una prueba de Merkle que verifica contra la raíz del estado actual.

● Retiro de activos de Rollup: El usuario inicia una transacción de salida, enviando los activos en su Rollup a la cuenta especificada para su destrucción. Si el operador agrega la transacción al siguiente lote, el usuario puede enviar una solicitud de retiro al contrato en cadena. Las solicitudes de retiro incluyen:

1. Prueba de Merkle, que demuestra que la transacción del usuario se agrega a la cuenta destruida en el lote de transacciones

2. Datos de la transacción

3. Agrupa la raíz

4. Dirección de red Layer1 para recibir fondos depositados

El contrato consolidado aplica un algoritmo hash a los datos de la transacción, comprueba si existe la raíz del lote y utiliza la prueba de Merkle para comprobar si el hash de la transacción forma parte de la raíz del lote. El contrato ejecuta la transacción de salida y envía los fondos a una dirección en la red de capa 1 seleccionada por el usuario.

Elementos de auditoría

La Capa 2 es un sistema completo de blockchain, por lo que los elementos comunes de auditoría para blockchains también se aplican a ZK Rollup, como se detalla en el apéndice al final de este artículo.

Además, debido a su naturaleza especial, ZK Rollup está obligado a realizar algunas auditorías adicionales:

● Prueba de seguridad del sistema: Verificar la seguridad y corrección de los esquemas de prueba de conocimiento cero utilizados (por ejemplo, Groth16, Plonk, Halo2, zk-STARK, etc.).

● Seguridad del circuito: Compruebe posibles vulnerabilidades en el diseño e implementación del circuito, principalmente incluyendo lo siguiente:

1. Circuitos poco restringidos

2. Circuitos sobredimensionados

3. Circuitos no deterministas

4. Sobrecarga/subdesbordamiento aritmético Sobrecarga/subdesbordamiento aritmético

5. Longitudes de bits no coincidentes

6. Entradas públicas no utilizadas optimizadas

7. Corazón Congelado: Forjando Pruebas de Conocimiento Cero

8. Fuga de configuración confiable

9. Asignado pero no restringido

10. Uso inseguro de componentes

11. Precisión variable

● Generación y validación de pruebas: Revisar el proceso de generación y validación de pruebas para asegurar que sea eficiente y seguro.

● Prueba de disponibilidad de datos: Asegurarse de que los datos de transacción de Layer2 estén disponibles en Layer1 para evitar la pérdida de datos.

● Mecanismo de sincronización de datos: compruebe si el mecanismo de sincronización de datos entre la capa 1 y la capa 2 es sólido y puede manejar situaciones anormales como la partición de la red.

● Proceso de depósito y retiro: Verifique el proceso de depósito y retiro desde Layer1 hasta Layer2 y desde Layer2 hasta Layer1 para garantizar que el proceso sea seguro.

● Creación y destrucción de activos: Verificar la lógica de creación y destrucción del activo en Layer2 para garantizar la correspondencia correcta con el activo en Layer1.

● Escaneo de dependencias externas y vulnerabilidades conocidas: ZK Rollup a menudo depende en gran medida de repositorios o herramientas criptográficas y matemáticas de terceros y debe verificar minuciosamente su seguridad de dependencia para escanear y validar vulnerabilidades conocidas.

Apéndice

Lista de auditoría general de Blockchain y Layer2:

● Desbordamiento de enteros: Verifique los desbordamientos de enteros y los subdesbordamientos de enteros

● Bucle: Verifique el bucle del programa para ver si la condición es razonable

● Llamada recursiva infinita: compruebe si la condición de salida de la llamada recursiva del programa es razonable

● Race condition: Comprueba el acceso a recursos compartidos en estado concurrente

● Error de excepción: Verifique el código de lanzamiento de excepciones que hace que el programa salga activamente

● Vulnerabilidad de división por 0: Verifique si hay un caso de división por 0

● Conversión de tipos: compruebe si la conversión de tipos es correcta y si se pierde información importante durante la conversión

● Array out of bounds: Comprueba el acceso a elementos fuera de los límites del array

● Vulnerabilidad de deserialización: Verifique problemas durante la deserialización

● Seguridad en la implementación de funciones: Verificar si la implementación de las interfaces RPC tiene riesgos de seguridad y es coherente con el diseño funcional de las interfaces RPC

● Si los ajustes de permisos de la interfaz RPC sensible son razonables: Verificar los ajustes de permisos de acceso de la interfaz RPC sensible

● Mecanismo de transmisión cifrada: Verificar si se utiliza un protocolo de transmisión cifrada, como TLS

● Análisis del formato de datos de solicitud: Verifica el proceso de análisis de formato para los datos de solicitud

● Ataque de desbloqueo de cartera: cuando un nodo desbloquea su cartera, se le pide por RPC que robe fondos

● Seguridad web tradicional: compruebe si hay las siguientes vulnerabilidades: secuencias de comandos entre sitios (XSS)/inyección de plantillas/vulnerabilidad de componentes de terceros/contaminación de parámetros HTTP/inyección SQL/inyección de entidades XXE/vulnerabilidad de deserialización/vulnerabilidad SSRF/inyección de código/inclusión de archivos locales/inclusión de archivos remotos/inyección de ejecución de comandos y otras vulnerabilidades tradicionales

● Mecanismo de autenticación e identificación de la identidad del nodo de la red: verificar si existe un mecanismo de identificación de la identidad del nodo, el mecanismo de identificación de la identidad del nodo puede ser eludido

● Contaminación de la tabla de enrutamiento: Verifique si la tabla de enrutamiento puede ser insertada o sobrescrita arbitrariamente

● Algoritmo de descubrimiento de nodos: compruebe si el algoritmo de descubrimiento de nodos está equilibrado e impredecible, por ejemplo, el algoritmo de distancia está desequilibrado

● Auditoría del uso de la conexión: Verificar si el límite y la gestión del número de nodos conectados a la red p2p son razonables

● Ataques de Eclipse Solar: Evaluar los costos y peligros de los ataques de eclipse solar, proporcionando análisis cuantitativo si es necesario

● Ataque Sybil: Evaluación de mecanismos de consenso de votación y análisis de estrategias de verificación de elegibilidad para votar

● Ataque de escucha: Verificar si el protocolo de comunicación revela privacidad

● Ataque alienígena: Evalúa si el nodo puede reconocer el mismo tipo de nodo de cadena

● Secuestro del tiempo: Verificar el mecanismo de cálculo del tiempo de la red de un nodo

● Ataque de agotamiento de memoria: Verificar el consumo de memoria elevado

● Ataque de agotamiento del disco duro: Verificar dónde se almacenan los archivos grandes

● ataque de presión de socket: Verificar la política de límite en el número de enlaces

● Ataque de agotamiento del controlador del kernel: Verificar las limitaciones en la creación del controlador del kernel, como los controladores de archivos

● Fugas de memoria persistentes: Verificar fugas de memoria

● Seguridad del algoritmo hash: verifique la resistencia a la colisión del algoritmo hash

● Seguridad del algoritmo de firma digital: Comprobar la seguridad del algoritmo de firma y de su implementación.

● Seguridad del algoritmo de cifrado: compruebe la seguridad del algoritmo de cifrado y la implementación del algoritmo

● Seguridad del generador de números aleatorios: compruebe si el algoritmo clave de generación de números aleatorios es razonable

● Seguridad de la implementación de BFT: Evaluar la seguridad de la implementación de algoritmos BFT

● Reglas de selección de bifurcaciones: Verifique las reglas de selección de bifurcaciones para garantizar la seguridad

● Prueba de grado de centralización: Identificar si hay un diseño demasiado centralizado en el diseño del sistema

● Auditoría de incentivos: Evaluar el impacto de los incentivos en la seguridad

● Ataques de doble gasto: comprueba si el consenso puede defenderse de los ataques de doble gasto

● Auditoría de ataque MEV: Examina el impacto del MEV del nodo de paquete de bloque en la equidad de la cadena

● Auditoría del proceso de sincronización de bloques: Verifica problemas de seguridad durante la sincronización

● Auditoría del proceso de análisis de formato de bloque: comprueba si hay problemas de seguridad durante el análisis de formato, como errores de análisis que provocan bloqueos

● Auditoría del proceso de generación de bloques: Verificar problemas de seguridad en el proceso de generación de bloques, incluyendo si la raíz del árbol de Merkle se construye de manera razonable

● Auditoría del proceso de verificación de bloques: Comprobar si los elementos de firma de bloque y la lógica de verificación son suficientes

● Auditoría de lógica de validación de bloques: Verificar si el algoritmo y la implementación de validación de bloques son razonables

● Colisión de hash de bloque: Compruebe cómo se construye la colisión de hash de bloque y si la colisión se maneja de manera razonable

● Límites de recursos de procesamiento de bloques: compruebe si los grupos de bloques huérfanos, la computación de verificación, el direccionamiento del disco duro y otros límites de recursos son razonables

● Auditoría del proceso de sincronización de transacciones: verifica problemas de seguridad en el proceso de sincronización

● Colisiones de hash de transacción: Examine cómo se construyen las colisiones de hash de transacción y cómo se manejan

● Análisis de formato de transacción: Verificar problemas de seguridad durante el análisis de formato, como errores de análisis que causen bloqueos

● Comprobación de la validez de la transacción: Compruebe si los elementos de firma de cada tipo de transacción y la lógica de verificación son suficientes

● Límites de recursos de procesamiento de transacciones: Verificar si los límites de recursos como los pools de transacciones, la computación de verificación y la dirección del disco duro son razonables

● Ataque de maleabilidad de transacciones: Si una transacción puede cambiar campos internos (como ScriptSig) para cambiar el hash de la transacción sin afectar la validez de la transacción

● Auditoría de ataques de reproducción de transacciones: Verifica la detección del sistema de reproducción de transacciones

● Comprobación del código de bytes del contrato: compruebe la seguridad del proceso de verificación del contrato de la máquina virtual, como el desbordamiento de enteros y los bucles muertos

● Ejecución de bytecode de contrato: Verificar la seguridad del proceso de ejecución de bytecode de la máquina virtual, como el desbordamiento de enteros, bucles infinitos, y así sucesivamente

● Modelo de gas: Verifique que las tarifas para cada operación atómica del procesamiento de transacciones/ejecución de contratos sean proporcionales al consumo de recursos.

● Integridad del registro: Verifique si se registran las informaciones clave

● Seguridad de registros: Verificar si el manejo inadecuado de registros causa problemas de seguridad, como el desbordamiento de enteros

● Los registros contienen información privada: Verifique si los registros contienen información privada como claves

● Almacenamiento de registros: Verifique si se registra un contenido excesivo en los registros, lo cual consume los recursos del nodo

● Seguridad del código de nodo de la cadena de suministro: Verificar todos los componentes, bibliotecas de terceros y versiones de los marcos de cadena pública en busca de problemas conocidos.

Descargo de responsabilidad:

1. Este artículo es reimpreso de [Beosina]. Todos los derechos de autor pertenecen al autor original [ Beosina]. Si hay objeciones a esta reimpresión, por favor contacte al Aprendizaje de la puertaequipo y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente 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, está prohibido copiar, distribuir o plagiar los artículos traducidos.