原文: Fragmentación de datos de seguridad variable —— polinia
Traductor: Evelyn|W3.Hitchhiker
Descargo de responsabilidad: Todo aquí es pensamiento puramente especulativo, hay muchas simplificaciones excesivas, nada de esto debe tomarse en serio, solo espero que haya algo en qué pensar.
La hermosa idea de Danksharding es la siguiente: solo el constructor (que de todos modos es una suposición minoritaria honesta) necesitará ejecutar el costoso hardware. Con el tiempo, los paquetes acumulativos escalan a millones de TPS con un costo mínimo para los validadores, los usuarios y todos los demás. El problema es que llevará tiempo demostrar esta ambiciosa visión. Podría ser entre 2 y 5 años, dependiendo de a quién le pregunte, por supuesto. Si bien el espacio criptográfico siempre ha sufrido falacias de planificación extremas, las cosas definitivamente están mejorando, pero me niego a confiar en ninguna hoja de ruta hasta que pueda ver un prototipo completamente funcional.
EIP-4844 es una gran mejora y creo que será más que suficiente para todas las aplicaciones y transacciones valiosas que requieren alta seguridad en el futuro previsible, y permite que los acumuladores se expandan 100 veces la actividad actual ~ 1000 veces. Sin embargo, habrá diferentes categorías de aplicaciones ávidas de datos que pueden requerir "millones de TPS" sin necesidad de alta seguridad.
Al mismo tiempo, está claro que los desarrolladores no tienen intención de esperar hasta que se complete el danksharding. Hoy en día, de los 15 proyectos principales de L2Beat, 7 no son acumulaciones, sino validiums y cadenas optimistas que utilizan capas de disponibilidad de datos externas. (Aquí supongo que está familiarizado con estas estructuras y sabe por qué siguen siendo mejores que las cadenas laterales, etc.) StarkEx (¡6 validiums ahora!), Arbitrum y Metis ya tienen capas de disponibilidad de datos externas, mientras que StarkNet, zkSync, Polygon y otras empresas sí las tienen; construyendo capas internas de disponibilidad de datos, sin mencionar empresas como EigenDA o Celestia. Estas soluciones híbridas no requieren ni EIP-4844 ni danksharding completo para mantener bajas las tarifas de transacción y, lo más importante, ya están aquí.
Una forma es dejarles hacer lo suyo y los usuarios elegirán la opción validium menos segura si la necesitan (pero aún más alta que alt-L1). La magia de Volitions es que los usuarios pueden elegir por transacción o por usuario.
Pero otro enfoque es: ¿Cómo podemos mejorar la capa de disponibilidad de datos externos?
Si bien esto está lejos de ser una muestra representativa, el 20% de los validadores de Ethereum hoy excede el rango típico. Mientras tanto, el 45% prefiere tener requisitos de tráfico y ancho de banda muy conservadores. Con EIP-4844, estamos optimizando este 45%, pero el 55% restante seguirá funcionando con un ancho de banda infrautilizado. Entonces, la idea es utilizar este ancho de banda libre agregando una fragmentación de datos simple, donde se dividirá el conjunto de validadores. No sé nada sobre ingeniería, pero confío en la palabra de Dankrad de que esto es "trivial".
Con EIP-4844, tenemos una nueva capa de disponibilidad de datos. Lo llamo fragmento de datos número 0 (DS0). DS0 es obligatorio y está garantizado por el conjunto completo de validadores de Ethereum.
Aquí podemos tener más fragmentos de datos (S1, DS2...etc.) que los validadores pueden aceptar. Por lo tanto, el 30% del campo anterior de 2 TB a 10 TB puede ejecutar 2 o 3 fragmentos de datos. Entonces, mientras que DS0 está garantizado por el 100% del conjunto de validadores de Ethereum, DS1 es del 55%, DS2 es del 50%, y así sucesivamente. Ahora que tenemos en ejecución a esos validadores de hiperespecificación (que aparentemente pensaron erróneamente que eran validadores de Solana) que se sienten cómodos con un tráfico de más de 20 TB o un ancho de banda de más de 100 Mbps, ese 20% también puede ejecutar más fragmentos. Entonces, su último fragmento de datos (DS16) solo proporciona el 10% de la seguridad de Ethereum. Por supuesto, lo hago parecer casual, pero dependiendo de la estructura del comité de Beacon Chain, puede haber algunas divisiones claras. Pero lo esencial es que DS0 viene con 100% de seguridad (por lo que todos los paquetes acumulativos serán HRE). DS1 es 50 % seguro, DS10 es 25 % seguro, DS16 es 10 % seguro, y así sucesivamente, para un nuevo tipo de construcción, se encuentra entre la acumulación completa (DS0/100 % seguro) y la cadena de validez/optimista.
En realidad, como vemos muchas validaciones y capas de datos en línea, la seguridad requerida para cada aplicación, usuario y caso de uso es un espectro. No es necesario que todo esté garantizado por cientos de miles de millones de dólares en seguridad económica.
Pero la cuestión es que, si asumimos que el 30% del suministro de ETH está en juego, incluso el DS16 de "seguridad mínima" todavía está respaldado por $5 mil millones en seguridad económica incluso en este mercado bajista, y ese sigue siendo el rango de seguridad de nivel alt-L1 superior. . También es importante recordar que este perímetro de seguridad es sólo para disponibilidad de datos. ¡Las pruebas de validez y las pruebas de fraude aún se verifican con 100% de seguridad! Por lo tanto, incluso un DS16 mitad rollup/mitad validium tiene una seguridad significativamente mejor que un alt-L1 de primer nivel.
Esto aún puede representar una mejora significativa con respecto a la opción de capa de datos externa. Sin duda, las transacciones financieras de alto valor optarán por liquidarse en DS0, pero algunas NFT de valor medio pueden requerir solo DS8, y para aplicaciones de juegos de valor cero, incluso DS16 puede ser redundante. Como se mencionó anteriormente, en un entorno voluntario, cada aplicación puede elegir el nivel de seguridad que requiere en función de sus propias circunstancias.
¿Qué pasa con los usuarios acumulativos? Solo necesitan ejecutar los fragmentos de datos asociados con ellos, por lo que los requisitos del sistema no serán diferentes de los de EIP-4844. Es por eso que incluso si existen compromisos de seguridad, no hay compromisos de descentralización en relación con EIP-4844. (A menos que sea un gigarollup distribuido en múltiples fragmentos de datos, pero eso es algo de lo que sus usuarios estarán muy conscientes)
Para ser claro, no espero que estas cosas sucedan, son sólo las divagaciones de un blogger aficionado loco y sin conocimientos técnicos. El camino de menor resistencia es llegar a EIP-4844 en 2023, y una vez que se sature en unos pocos años, los casos de uso ávidos de datos se extenderán a muchas capas de datos externos, y todos los datos estarán altamente mercantilizados y enriquecidos. Finalmente, con el paso de los años, danksharding apareció en línea y se convirtió en la mejor solución. Pero tal vez alguien lea esto y encuentre una mejor idea para llenar el enorme vacío entre 4844 y la fragmentación completa...
