Traducción del articulo de Ye Zhang@Scroll - “The midset behind Scroll”

Los zkEVM se han convertido en un tema muy popular en los últimos 2 años. Podría decirse que se han convertido en la tecnología de oro estándar para escalar Ethereum, no solo a través de la layer 2, sino también directamente a través de la layer 1, "snark Ethereum itself for the end game". Hemos estado impulsando este ambicioso sueño junto con el equipo de Privacy and Scaling Exploration desde el principio, y nos hemos comprometido a seguir construyéndolo en conjunto en el futuro.

En este artículo, quiero compartir algunas de las lecciones que aprendimos mientras construíamos zkEVM, y cómo hemos estado pensando en diferentes trade-offs a lo largo del camino. Estamos adoptando un enfoque diferente al de otros proyectos en el ecosistema, y ​​esto nos coloca en una posición única.

Scroll es fundamentalmente posible gracias al open-source. Estamos utilizando proving stack de Zcash y hemos estado construyendo zkEVM circuits junto con el equipo de PSE desde el primer día. Agradecemos el esfuerzo de la comunidad y todas las herramientas que se están construyendo. Con ese espíritu, una mentalidad importante que tenemos es devolver todo lo que podamos y continuar construyendo con la comunidad de una manera más abierta y colaborativa. Esto distingue nuestro ethos de otros proyectos. Más específicamente, hemos hecho lo siguiente para que el desarrollo de Scroll esté orientado a la comunidad:

• Educación pública para un público amplio. Para ayudar a las personas a comprender nuestra arquitectura, hemos dado múltiples charlas y organizado eventos a nivel mundial. Puede encontrarnos en Devconnect, SBC, Devcon, etc. Para los estudiantes que desean aprender más, hemos dado conferencias en 0xPARC sobre nuestro proving stack, así como presentaciones en Stanford y Berkeley sobre nuestra investigación. Para los auditores, hemos organizado sesiones especiales de auditores sobre nuestro código base. También creamos con frecuencia recursos educativos para las comunidades generales de zk y Ethereum: organizamos una serie semanal de investigación aplicada de zk y compartimos publicaciones técnicas sobre zk tech y Ethereum.

• Desarrollar con la comunidad. Nuestro zkEVM se ha desarrollado a través de un enfoque totalmente impulsado por la comunidad desde el primer día. Además de nuestro equipo y el equipo de PSE, hay varios miembros de la comunidad que contribuyen a diferentes partes de zkEVM (por ejemplo, muchos opcode circuit han sido implementados en paralelo por diferentes miembros de la comunidad, y se han realizado optimizaciones sorprendentes tanto en el keccak circuit como en el snark -verifier). También dirigimos una community call quincenal para mejorar el proving stack subyacente . Ya se ha logrado un progreso asombroso; por ejemplo, Goldilocks y FRI ahora son compatibles con Halo2. ¡Una base sólida gracias al esfuerzo de la comunidad permite la seguridad y la auditoría compartida!

Los beneficios de construir a través de un enfoque impulsado por la comunidad son claros. Podemos intercambiar ideas con un grupo grande y obtener ideas más creativas. Podría decirse que también es más seguro, ya que cada pull request recibe más reviews de otros miembros de la comunidad. Algunas partes comunes incluso se pueden compartir entre proyectos; por ejemplo, Axiom ha implementado un pairing circuit, que es una de las precompilaciones de zkEVM más difíciles.

Sin embargo, hay ciertos trade-offs que vienen con la construcción abierta. Es más difícil coordinarse en un grupo grande (no solo en términos de comunicación, sino también de prioridades). Puede ralentizar el desarrollo, ya que muchos pull requests requieren reviews y el estándar para el merging es de un nivel de exigencia alto.

Algo exclusivo de nuestro zkEVM es que también mantenemos un python spec, similar a lo que ha estado haciendo Ethereum para su consensus-spec y execution-spec. Mantener esta especificación permite a las personas que no están familiarizadas con Rust y Halo2 de low-level comprender el circuit logic. Hasta donde yo sé, ninguna otra implementación de zkEVM se toma el tiempo para hacer esto, de modo que puedan enviar más rápido y acercarse a mainnet de manera más agresiva.

En Scroll, estamos adoptando este enfoque impulsado por la comunidad para desarrollar todo el zkEVM. Creemos que el camino correcto a seguir es construir con la comunidad desde el principio. Tenga en cuenta que el "desarrollo impulsado por la comunidad" significa mucho más que ser solo open-source. No significa construir en privado y luego, de repente, abrir todo el código algún día. Debe medirse por cuántos external contributors hay y cómo se desarrolló el proyecto a lo largo del tiempo. Aceptamos el trade-off de ser más lentos en las primeras etapas, pero creemos en el poder del desarrollo impulsado por la comunidad en las etapas posteriores a medida que nuestra comunidad continúa creciendo.

Ethereum ha adoptado una estrategia similar para lograr su visión y valores llamada "sustracción". La idea es bastante simple: en lugar de construir todo por su cuenta, apoyan a la comunidad tanto como pueden. Les ayuda a buscar el equilibrio adecuado y centrarse en las cosas que son realmente importantes para ellos. Estamos haciendo exactamente lo mismo. Nos preguntamos: "¿Qué tipo de apoyo podemos brindar a la comunidad para ayudarlos a construir?" Creemos que nuestro enfoque de base y orientado a la comunidad nos llevará a una posición única en el espacio.

Esta mentalidad nos diferencia de otros competidores que tienen un gran ejército de personas que crean múltiples soluciones internas y que comercializan locamente en todas las direcciones. Solo nos enfocamos en enviar la pieza más importante y liderar en la dirección correcta.

La seguridad es la principal razón por la que la gente cree en la layer 2 en comparación con la layer 1 alternativa: puede heredar la seguridad de Ethereum sin confiar en los operadores de la layer 2. Pero todos los proyectos de layer 2 existentes todavía están lejos de ese estándar, con diferentes training wheels en su lugar. Por ejemplo, para los optimistic rollups, incluso si muchos ya se han lanzado en mainnet, aún necesitan upgradable keys y no admiten permissionless fraud proofs.

Para los zkEVM, también es un gran problema: cada player está en una carrera larga y necesita múltiples iteraciones, independientemente de cuán agresivo sea su approach de acercarse a mainnet. Todavía hay problemas fundamentales relacionados con zkEVM que no se han resuelto. Por ejemplo, el costo del prover será diferente del execution cost, y esto influirá en el gas pricing de la layer 2 o introducirá vulnerabilidades de seguridad.

Hemos reflexionado sobre los problemas de seguridad y hemos tratado de tomar las mejores decisiones. Enumero algunas de esas decisiones a continuación:

• Adopte un enfoque EVM-equivalent. Una razón importante para adoptar este enfoque es que conduce a una mejor developer experience, pero otra razón más profunda es heredar la seguridad del modelo EVM, que ya ha sido probado en batalla. También estamos reutilizando infraestructura como Geth para minimizar nuestra diferencia con Ethereum. Esto garantiza que nuestro secuencer de layer 2 se comporte exactamente igual que un nodo de layer 1, lo que maximiza la seguridad.

• Enfoque orientado a la comunidad. Como mencioné anteriormente, obtener reviews de reviews de la comunidad externa brinda una garantía más sólida para la seguridad del código. El tooling y el proving stack también se comparten entre proyectos, por lo que prestamos más atención al código base actual. Una buena medida debería ser "¿Cuántas personas están familiarizadas con su código base?", "¿Cuántas personas lo están usando seriamente?"

• Auditoría, auditoría y auditoría. Test, test y test. Hemos organizado sesiones de auditores para enseñarles a los auditores sobre nuestro development stack y hemos contratado a los mejores auditores de la industria para nuestros zkEVM circuits, pero las auditorías externas no son suficientes. Internamente, hemos integrado los test vectors EVM estándar y hemos realizado numerosas simulaciones para probar los bloques de la red principal. Además de eso, también otorgamos grants para respaldar exploraciones como verificación formal y fuzzing para nuestro zkEVM.

• Investigación sobre training wheels. Internamente, hemos estado investigando varias soluciones para eliminar las training wheels y cómo garantizar 2FA o 3FA para nuestro zkEVM. Creemos que esto es lo más importante que hay que hacer, aunque tiene menos ruido de marketing que tener nuevas funciones más sofisticadas. Como siempre, compartiremos nuestros hallazgos y discutiremos con la comunidad a medida que avancemos.

**Para mantener un alto nivel de seguridad, optamos por hacer que cada versión sea más estable y repetir la versión existente para seguir mejorando la solidez y la performance. **Haremos que todo sea aún más transparente en nuestros hilos de actualizaciones semanales .

Nuestra mentalidad de seguridad primero es la influencia más fuerte con respecto a nuestro roadmap. Nos ayuda a decidir qué camino debemos tomar al mismo tiempo que responde preguntas como:

• "¿Deberíamos apuntar a la EVM-equivalence o la Ethereum-equivalence en este momento?"

• "¿Deberíamos descentralizar el prover o secuencer primero?"

• "¿Deberíamos seguir agregando nuevas funciones o centrarnos en eliminar las training wheels?"

Iré desgranando cada una de esas preguntas en los siguientes posts.

Piense en la historia de Ethereum y por qué la gente piensa que es creíblemente neutral . No es solo por la tecnología superior, sino también por el camino que tomó para llegar a donde está hoy. Ethereum está descentralizado en cada layer (transparencia en la toma de decisiones, consenso social, etc.). Del mismo modo, definimos la descentralización a través de múltiples layers diferentes y establecemos un estándar extremadamente alto para nosotros mismos:

• prover descentralizado. Somos los primeros en proponer la idea de una proving network descentralizada. Es el primer paso técnico que daremos para lograr la descentralización total y garantizar una alta confiabilidad. Un objetivo de optimización es reducir el proving cost, lo que permitirá que más personas ejecuten un prover, descentralizando aún más el sistema. Estamos trabajando conscientemente para evitar el dilema de que "el prover más rápido siempre gana", de modo que las personas no tengan que depender de costosos hardware personalizados para participar en nuestra red.

• secuencer descentralizado. Descentralizar el secuencer es otro paso importante que puede ayudar con la censorship-resistance y estamos comprometidos a trabajar en ello. Tenemos múltiples propuestas internas sobre cómo lograr esto, y pronto haremos públicas estas ideas para una discusión más amplia. Hay muchas razones por las que queremos descentralizar primero el prover (p. ej., preocupaciones sobre bug-free zkEVM y una interacción e incentivos más complicados entre el prover y el secuencer). Estamos pensando a muy largo plazo en cómo alinearnos con Ethereum a nivel de protocolo con respecto a los secuencers.

• desarrollo y gobernabilidad. El desarrollo de zkEVM se ha realizado de forma descentralizada con una comunidad de open-source contributors. Nos coordinamos con ellos a través de community calls zkEVM y prover. A medida que avancemos, haremos que el desarrollo y la gobernanza sean cada vez más transparentes (incluido el proceso de toma de decisiones de desarrollo, similar a las calls ACD de Ethereum).

• ecosistema y comunidad. Siguiendo la visión de Ethereum de "the infinite garden", queremos apoyar el crecimiento orgánico de nuestro ecosistema y comunidad. Por lo tanto, minimizaremos los "partnerships" con proyectos individuales específicos y, en cambio, nos mantendremos en una posición más neutral para apoyar todos los esfuerzos de base. No estamos pensando en términos de marketing, sino en términos de mensajería y comunicación. Nos preguntamos, “¿Cómo podemos ser más transparentes con nuestra comunidad?” Creemos que este enfoque es la mejor manera de crear un ecosistema más descentralizado y fomentar la creatividad.

• diversidad social y cultural. Además de la tecnología y el ecosistema, apuntamos a otro nivel de descentralización a nivel social y cultural. Nuestro equipo está distribuido en varios continentes (Asia, Europa, América del Norte, América del Sur, Australia). Puede encontrar un miembro del equipo de Scroll en casi cualquier parte del mundo, y esto nos permite desarrollar una comunidad distribuida a nivel local. Estamos creciendo con la diversidad cultural para un nivel más profundo de consenso social.

Nos mantenemos altamente alineados con Ethereum mientras desarrollamos nuestra scaling solution. Ethereum tiene un objetivo final ambicioso de "todo zk-SNARK": construir un Ethereum-equivalent zkEVM que se pueda usar para probar bloques de red principal. Imagine que un día, los validadores no necesitan volver a ejecutar un bloque de layer1, sino que solo verifican un succinct zk proof. Imagina que un día puedes probar toda la historia de Ethereum a través de una sola proof. ¿No es súper emocionante?

¡Este es exactamente el objetivo del equipo de PSE! Como el co-constructor más grande que desarrolla sobre la misma base de código durante aproximadamente 2 años, estamos avanzando directamente hacia este ambicioso objetivo.

Se ha propuesto algún estándar para categorizar diferentes tipos de zkEVM. Sin embargo, es más una especificación de alto nivel que describe lo que se debe hacer como resultado final. Como una de las principales fuerzas que impulsan Ethereum-equivalent zkEVM, queremos proponer algo diferente para distinguir el objetivo y el camino práctico para llegar allí. Este es el camino que queremos tomar para snark Ethereum:

• Implemente un zkEVM compatible con el nivel de bytecode con una sound zk proof

• Trabajar en iniciativas relacionadas para coordinar el desarrollo de la layer 1 y zkEVM

• Alcance un estándar comunitario y proponer EIP para mejorar Ethereum para el end game

En este momento, estamos en la primera fase del lanzamiento de un zkEVM compatible con bytecode listo para ser lanzado y nos hemos comprometido a seguir construyendo el futuro de Ethereum con toda la comunidad. Puede llevar años construir un Ethereum-equivalent zkEVM, lo suficientemente seguro y eficaz, lo que implica proof system upgrades, nuevos  circuit designs, así como innovaciones en la aceleración de software y hardware. Pero lo que es más importante, para adoptarlo en la layer 1, Ethereum tiene que hacer algunos cambios. Todas las actualizaciones importantes de Ethereum deben tener en cuenta zkEVM antes de lograr su objetivo final.

La idea prevaleciente ha sido que la layer 2 adapte los cambios unidireccionales para la layer 1. Sin embargo, a medida que maduran los rollups, creemos que este ya no debería ser el caso. Los rollups deben desempeñar un papel en la conducción de cambios en la layer 1, y los equipos de rollups deben desempeñar un papel más importante con respecto a la infraestructura de la layer 1 (4844, Danksharing, Verkle tree, PBS, Multidimensional fees, etc.). Debemos tener cuidado con las implicaciones de la compatibilidad con versiones anteriores, pero el legado no debe limitar el futuro. Todo el ecosistema debería coordinarse para un mejor Ethereum.

Hemos adoptado un enfoque impulsado por la comunidad para desarrollar zkEVM desde el principio, y nos hemos comprometido a seguir construyendo de una forma más colaborativa y a seguir devolviendo a la comunidad. Damos la máxima importancia a la seguridad y la descentralización, y nos estamos centrando en formas específicas de conseguirlas. Con nuestra mentalidad de seguridad, nos fijamos un alto estándar para ser más seguros y estables con cada versión. Con nuestra mentalidad de descentralización, perseguimos la descentralización en todos los niveles, incluida nuestro stack tech, el proceso de desarrollo, el ecosistema, la comunidad y la diversidad social.

Queremos impulsar al máximo la naturaleza open y censorship-resistant de las blockchains. Hemos elegido un camino que es único desde el principio. Nos hemos posicionado no sólo para construir una layer 2, sino también para impulsar el ambicioso objetivo de gruñir todo Ethereum. Con nuestra mentalidad, estamos operando como Ethereum, ¡y apuntando al mismo futuro the infinite garden!