# La mentalidad detrás de Scroll By [L2 en Español](https://paragraph.com/@layer2es) · 2023-02-27 --- Traducción del articulo de Ye Zhang@Scroll - [_“The midset behind Scroll”_](https://hackmd.io/@yezhang/B167uMZRs#) Introducción ------------ 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](https://www.reddit.com/r/ethereum/comments/vrx9xe/comment/if7auu7/)". 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. Desarrollo basado en la comunidad --------------------------------- Scroll es fundamentalmente posible gracias al _open-source_. Estamos utilizando [proving stack](https://github.com/zcash/halo2) de Zcash y hemos estado construyendo [zkEVM circuits](https://github.com/privacy-scaling-explorations/zkevm-circuits) junto con el [equipo de PSE](https://twitter.com/PrivacyScaling) 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](https://twitter.com/Scroll_ZKP/status/1521677531438628864), [SBC](https://www.youtube.com/playlist?list=PLrzRr7okCcmauITgMFrrXdxE-QQ75-i4_), [Devcon](https://www.youtube.com/playlist?list=PLrzRr7okCcmZKUhBNRXmK5vWmJMlQZzzD), etc. Para los estudiantes que desean aprender más, hemos dado [conferencias](http://learn.0xparc.org/materials/halo2/learning-group-1/cost-model) en 0xPARC sobre nuestro _proving stack_, así como presentaciones en [Stanford](https://www.youtube.com/watch?v=1bVe77-yfBA&list=PLhA8D_GhTLc5MR5aecbSfL6wvqGS8IOqK) y [Berkeley](https://www.youtube.com/watch?v=Ct6H5GcnA0A&t=2395s) sobre nuestra investigación. Para los auditores, hemos organizado [sesiones especiales](https://www.youtube.com/playlist?list=PLrzRr7okCcmZmDrVozX5hhBQlsrpZdsij) 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](https://youtube.com/playlist?list=PLrzRr7okCcmbAlgYpuFjzUJv8tAyowDQY) y compartimos publicaciones técnicas sobre [zk tech](https://scroll.io/blog/proofGeneration) y [Ethereum](https://scroll.io/blog/kzg). * **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](https://github.com/halo2-ce) subyacente . Ya se ha logrado un progreso asombroso; por ejemplo, [Goldilocks](https://github.com/halo2-ce/halo2/pull/11) y [FRI](https://github.com/maxgillett/halo2-fri-gadget) 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](https://twitter.com/axiom_xyz) ha implementado un [pairing circuit](https://github.com/axiom-crypto/halo2-lib), 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](https://github.com/privacy-scaling-explorations/zkevm-specs), similar a lo que ha estado haciendo Ethereum para su [consensus-spec](https://github.com/ethereum/consensus-specs) y [execution-spec](https://github.com/ethereum/execution-specs). 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](https://github.com/privacy-scaling-explorations/zkevm-circuits/graphs/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](https://www.youtube.com/watch?v=noXPewi5qOk)". 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.** ### Tenga en cuenta la seguridad y garantice un lanzamiento constante 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](https://ethereum-magicians.org/t/proposed-milestones-for-rollups-taking-off-training-wheels/11571) 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](https://github.com/ethereum/go-ethereum) 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](https://ethresear.ch/t/2fa-zk-rollups-using-sgx/14462) 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](https://twitter.com/Scroll_ZKP/status/1621573571259793408) . 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 _secuence_r 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. ### La descentralización es importante en todas las capas Piense en la historia de Ethereum y por qué la gente piensa que es [creíblemente neutral](https://nakamoto.com/credible-neutrality/) . 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](https://scroll.io/blog/architecture). 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](https://twitter.com/Scroll_ZKP/status/1621573597566468096), 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](https://github.com/ethereum/pm) de Ethereum). * **ecosistema y comunidad.** Siguiendo la visión de Ethereum de "[the infinite garden](https://ethereum.foundation/infinitegarden)", 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. ### No construye sólo para Scroll, sino también para Ethereum 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](https://vitalik.ca/general/2022/08/04/zkevm.html). 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](https://www.eip4844.com/), [Danksharing](https://notes.ethereum.org/@dankrad/new_sharding), [Verkle tree](https://vitalik.ca/general/2021/06/18/verkle.html), [PBS](https://notes.ethereum.org/@domothy/pbs_links), [Multidimensional fees](https://ethresear.ch/t/multidimensional-eip-1559/11651), 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. ### Conclusión 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_!** --- *Originally published on [L2 en Español](https://paragraph.com/@layer2es/la-mentalidad-detr-s-de-scroll)*