¿Qué problema quiere resolver Layer2? ¿Cómo definir un Rollup seguro y descentralizado?
Introducción
Cuando observamos la visión y la hoja de ruta de varias soluciones de Rollup, encontraremos que casi todos los Rollup tienen un objetivo final. Si este objetivo se condensa en una oración: construir una pila de tecnología, proporcionarla a la comunidad, resolver La expansión de la blockchain y, en última instancia, la descentralización de la pila tecnológica de operaciones y gobernanza. Esto lleva al término resumen descentralizado.
Entonces, ¿qué es exactamente la descentralización? ¿Cuál es la división del trabajo entre las distintas partes del sistema Rollup? ¿La descentralización significa maximizar los participantes en la operación del sistema? ¿Qué impacto tendrá un clasificador centralizado? ¿Cómo se debe diseñar el ordenamiento compartido y el consenso local L2? ¿Cuál es la función del probador único en ZK-Rollup? ¿Cómo sería una red de probadores abierta y descentralizada? ¿Por qué necesitamos la aceleración de hardware zk? ¿Cuál es la solución al problema de disponibilidad de datos? ....
Hay discusiones interminables sobre el resumen descentralizado en la comunidad, por lo que ECN seleccionó una serie de entrevistas de podcast con el tema "Resumen descentralizado" e invitó a fundadores e investigadores destacados en este campo para hablar sobre su comprensión del resumen descentralizado.
El primer número invitó a Patrick McCorry, investigador de la Fundación Arbitrum.Este episodio sirve como un resumen de la serie, hablando principalmente sobre los problemas que la capa 2 quiere resolver, el significado del resumen descentralizado, cómo entender sus atributos de seguridad y cómo Gobernanza DAO Funciona en rollup descentralizado.
Invitado de este episodio: Patrick McCorry, twitter @stonecoldpat0
Moderador: Franci, twitter@FrancixDeng
Remolque
Fase 2: Secuenciador Compartido y Consenso L2
Yao Qi, fundador de AltLayer Network
Investigador de pergaminos Toghrul Maharramov
Líder de exploración de StarkNet, Abdelhamid Bakhta
Problema 3: Prover network y aceleración de hardware zk
Ye Zhang, cofundador de Scroll
Leo Fan, cofundador de Cysic
Problema 4: Disponibilidad de datos y almacenamiento descentralizado
Qi Zhou, fundador de EthStorage
Escuchar
Haga clic para suscribirse al podcast para obtener más información:
YouTube:
Microcosmo:
Marca de tiempo
01:49 Introducción a los antecedentes personales de Patrick McCorry
03:26 ¿Por qué existe la capa 2 y qué intenta resolver?
11:56 ¿Qué armas están usando para mantener seguros a los usuarios?
14:40 Qué significa la seguridad y vivacidad de Rollup
17:47 Explicar la seguridad del resumen desde la disponibilidad de datos, la validez de la transición de estado y la anticensura
19:45 El papel de la única entidad honesta, ¿quién actúa como la única entidad honesta acumulada?
28:47 ¿Qué opinas del resumen descentralizado? ¿Cuál es el objetivo más apremiante en este momento?
37:21 La importancia de la gobernanza de DAO en un resumen descentralizado
Sección de entrevistas
Problemas que Layer2 quiere resolver
Franci: Lo que vamos a explorar en este episodio es, ¿qué significa tener un Rollup descentralizado? Por qué es importante ¿Qué problema están tratando de resolver? Espero que a través de esta charla, los lectores y oyentes finalmente puedan comprender qué es un resumen descentralizado real y qué objetivos deben cumplir. Deje que nuestro invitado, Patrick McCorry, se presente.
patricio: hola a todos Creo que por experiencia, estoy sesgado hacia la investigación académica. De 2013 a 2016, mi dirección doctoral estuvo relacionada con Bitcoin y Ethereum. Luego, desde 2016 hasta alrededor de 2019, fui investigador en universidades como UCL, King's College London y UIUC. Durante este tiempo, he estado muy interesado en los protocolos de Capa 2. Incluye Bitcoin Lightning Network, plasma y, por supuesto, Rollup. Entonces, en 2019, intenté hacer una startup. Luego dejé la universidad, mi amigo y yo, básicamente dos personas y un perro. Estamos tratando de ser una empresa nueva enfocada en la capa 2. Pero era un mercado bajista y luego fuimos adquiridos por Infura. Luego dejé Infura y recientemente me uní a la Fundación Arbitrum. Así que volví a centrarme en la investigación acumulada a tiempo completo. Durante todo este período, me he centrado principalmente en la educación, explicando por qué debemos preocuparnos por los protocolos de capa 2.
Franci: Comencemos con los temas más básicos. En general, ¿qué es un sistema L2? ¿Qué significa cuando un usuario deposita dinero en el sistema L2 y realiza una transacción allí?
Patrick: Hablando de este tema, creo que debemos dar un paso atrás y pensar, ¿cuál es el punto de blockchain? ¿Cuál es el punto de todos estos sistemas que estamos tratando de construir? Una vez que tengamos esto en cuenta, tiene un poco más de sentido explicar L2. Lo real detrás de una red blockchain como Bitcoin o Ethereum es solo una base de datos. es una base de datos pública en la que cualquiera puede leer y escribir. Por lo tanto, es una base de datos de saldos de cuentas y, por supuesto, en Ethereum, hay varios programas además de los saldos de cuentas. Entonces puedo implementar mi código en la base de datos. Mi programa puede tener algún estado y puedo hacer transacciones en él, y todos pueden ver las actualizaciones de la base de datos. Fundamentalmente, solo estamos tratando con bases de datos. Suena aburrido.
Y la importancia de la cadena de bloques en sí misma, en realidad es solo una pista de auditoría. Por lo tanto, almacena una lista de transacciones y, si le doy una copia de la cadena de bloques, puede volver a calcular esta base de datos usted mismo. Fundamentalmente, estamos construyendo una base de datos pública que cualquiera puede leer, calcular y escribir de forma independiente. Bueno, esta es la capa 1.
Ya sea la capa 1 de Bitcoin o Ethereum, el problema es que necesita maximizar la descentralización. Hay tres formas diferentes de pensar en la descentralización. Uno es el operador: quien maneja la red, quien produce bloques, quien confirma las transacciones. Con muchas de estas redes, siempre queremos maximizar la posibilidad de que cualquiera pueda participar en el proceso. De esta manera no hay un único punto de falla. Por otro lado, también debe considerar quién puede verificar cada actualización de la base de datos, quién puede verificar que los operadores estén haciendo su trabajo, que la base de datos sea correcta y si hay otros problemas. Sus trabajos y bases de datos son correctos y válidos en todo momento. En este punto, tendrás este problema. Desea maximizar la cantidad de personas que participan en la validación de la red y desea maximizar la cantidad de personas que ejecutan la red. Entonces, es algo así como la vieja pelea por el tamaño del bloque de Bitcoin. Actualice los bloques y podrá procesar más transacciones. Pero luego será más difícil, porque necesita requisitos de hardware más altos para verificar la red en tiempo real y finalmente convertirse en un operador de red. Esta es la cuestión de cómo considerar la descentralización a nivel de capa1. El tercer aspecto es hacerlo asequible. Si pagamos $200 para realizar transacciones en una red, ¿realmente está descentralizada? Aparentemente no lo es. Por lo tanto, en cierto sentido, este es un problema de trilema remanente de la historia.
Durante mucho tiempo, estuvimos atrapados en este trilema, porque si intenta procesar más transacciones, una de las partes se verá perjudicada de alguna manera, ya sea que aumenten las tarifas, aumenten los requisitos de hardware o se convierta en un problema. operativa más difícil. Esta es una discusión sobre la descentralización en el contexto de L1.
Franci: Como dijiste, los usuarios considerarán el costo de las transacciones. Entonces podrían optar por depositar su dinero en un intercambio centralizado. Hablando en términos generales, ¿es esto una especie de L2?
Patrick: Creo que es una buena manera de pensar en términos de intercambios. Un intercambio centralizado es como una base de datos. Pero el problema es que es una base de datos privada. Entonces, básicamente, la base de datos del intercambio, solo puede leer y escribir. Y usuarios como usted y yo, no podemos auditar esta base de datos, no podemos verificar que sea correcta. Pero la ventaja de operar en una bolsa es que es muy barato. El propósito del sistema de cadena de bloques L1 es estar lo más descentralizado posible, pero el costo es demasiado alto.
Entonces, cuando pensamos en el mundo L2, en el mundo L2, realmente no queremos recrear el L1. Realmente no queremos tener que construir una red descentralizada que maximice la cantidad de participantes. Porque ya sabemos que, históricamente, ha sido muy difícil construir este tipo de sistemas y hacerlos escalar mucho en términos de rendimiento. Entonces pensaríamos, ¿podemos construir un sistema que se parezca a un intercambio, pero aún conserva las propiedades de un sistema de cadena de bloques, donde la base de datos es pública? Cualquiera puede leer la base de datos, cualquiera puede escribir en ella y cualquiera puede protegerla. Este es el objetivo de L2.
Cuando empiezas a comparar intercambios con lo que hemos construido en L2, al final del día estamos comparando cosas de ingeniería de puentes. El puente del que hablo es que habrá un contrato inteligente en Ethereum, y bloqueo los activos en este contrato inteligente llamado "puente". Una vez bloqueado en el puente, aparecerá en otras bases de datos. Esta base de datos podría ser Coinbase, podría ser Arbitrum, podría ser Optimism. Entonces la pregunta es, cuando quiero sacar mis fondos de esta otra base de datos y devolverlos a Ethereum, ¿cómo me autorizan y cómo convenzo al puente para que desbloquee los fondos?
Para Coinbase, el usuario confía en Coinbase para autorizar el retiro, el contrato inteligente verificará y dirá, oh, Coinbase autorizado, puedo retirar los fondos. Pero para L2, la atención se centra en el puente y cómo hacer creer que esta base de datos fuera de la cadena es segura y luego permitir que se desbloqueen los fondos.
Entonces, volviendo a tu pregunta original. Creo que Coinbase o estos intercambios son básicamente lo que queremos construir para L2. Pero queremos construirlo de una manera que proteja a los usuarios. Si Coinbase deja de funcionar, o si hacen algo malo y son pirateados, los usuarios siempre están seguros y protegidos. No tienen que confiar en los operadores del sistema. En lo que realmente se enfoca es en cómo los activos se bloquean en el puente del sistema y luego se sacan de ese sistema.
Cómo definir un Rollup seguro y descentralizado
Franci: Entonces, lo que tiene que hacer Rollup es elegir algún compromiso entre estos. ¿Qué armas utilizan para mantener seguros a los usuarios?
Patrick: Creo que el enfoque real está en el puente mismo. Por ejemplo, el puente de Arbitrum, que es un conjunto de contratos inteligentes implementados en Ethereum. El puente actualmente tiene alrededor de $ 6 mil millones más o menos. En realidad, es un conjunto de contratos inteligentes en Ethereum con $ 6 mil millones. Debe convencer al puente de que tengo derecho a retirar mis fondos del puente y devolverlos a Ethereum.
Entonces, ¿qué armas tenemos para mantener seguros a los usuarios? Una de las cosas buenas de estar en L2 es que podemos hacer una muy buena suposición. Podemos suponer que ya existe un L1, como Bitcoin o Ethereum, que ya existe y se está ejecutando. Podemos suponer que ya existe esta plataforma descentralizada y construir sobre ella. Y piense en esta plataforma como un tercero de confianza, confíe en este tercero y garantice que siempre haremos lo correcto. Esa es la base de todos estos sistemas. Si tiene una buena plataforma descentralizada, aproveche y reutilice y construya sobre ella.
Entonces, la declaración del problema en realidad se convierte en, ahora tenemos esta base de datos fuera de la cadena que registra los saldos de las cuentas y los estados del programa. ¿Podemos usar un tercero de confianza para verificar que cada actualización de esta base de datos sea correcta y válida? De esto se trata realmente L2. Para dar un ejemplo concreto, digamos que en la base de datos de Arbitrum hay saldos de cuentas, estados de programas y luego el contrato inteligente de Arbitrum es un tercero confiable que garantiza que el puente siempre funcionará correctamente. Las personas que manejan la red de Arbitrum, los ordenantes, los validadores, envían periódicamente puntos de control o pruebas al puente para convencerlo de que las actualizaciones aplicadas a la base de datos son correctas y válidas. Si el puente está convencido, permitirá a los usuarios retirar sus fondos de Arbitrum. Así que esta es nuestra arma.
Franci: Acabas de decir que Rollup está construido sobre Ethereum. Esto me recuerda un dicho que la comunidad siempre dice que Rollup hereda la seguridad de Ethereum. Entonces, ¿significa esto que la seguridad de Rollup es equivalente a la de Ethereum?
Patrick: Creo que es una buena forma de pensar en ello. La respuesta es sí y no. Creo que hay diferentes maneras de pensar sobre esto. La forma más fácil es la seguridad y la vitalidad. En términos de seguridad, solo consideramos este problema en la base de datos, lo que significa que cada actualización de la base de datos es válida. Es imposible tener una actualización no válida, porque si hay una actualización no válida en la base de datos, puede robar los activos. Esto rompe la seguridad básica. Y eso es una gran parte de eso.
La siguiente parte es la vitalidad, lo que significa que podemos asegurarnos de que las personas puedan realizar actualizaciones en la base de datos. En una base de datos, para mantenerla viva, necesitamos garantizar, ¿siempre podemos actualizarla? ¿O hay un lado honesto? Pueden proponer una actualización, que finalmente se procesa. Esto es importante porque si Coinbase o Kraken fallan o hacen algo malo, sus fondos se estancarán. Ahí es donde es ligeramente diferente de Ethereum porque en Ethereum tienes que confiar en el PoS y en la mayoría honesta para mantener vivo el sistema. Mientras que en el resumen, ya asumimos que esta actividad se ha obtenido de forma gratuita de Ethereum. Solo tenemos que asumir que hay una fiesta honesta por ahí. Mientras haya una persona honesta dispuesta a hacer el trabajo y proponer actualizaciones a la base de datos, entonces, por supuesto, el sistema seguirá vivo. A esto nos referimos con heredar la seguridad de Ethereum.
Entonces, cuando pensamos en la seguridad de los paquetes acumulativos, en realidad no estamos pensando en una red descentralizada. Puede haber una red acumulada descentralizada, pero eso no importa. La seguridad de Rollup realmente depende de su contrato inteligente como puente, y debe convencerse de tres aspectos.
El primero es un problema de disponibilidad de datos: el puente cree que cualquier persona en el mundo puede acceder a la base de datos y cualquiera puede volver a calcular una copia de la base de datos y la copia más reciente. Así que esto es lo primero que tienes que convencer al puente. ¿Puede alguien en el mundo acceder a una copia de la base de datos que nos interesa?
La segunda propiedad, podría llamarla el problema de integridad de transición de estado, y esto se remonta al tema de la seguridad. El puente necesita confiar en que cada actualización de la base de datos sea correcta y válida. Y esto es para garantizar que nadie pueda robar sus fondos. Por lo tanto, el operador de acumulación tiene que convencer periódicamente al puente de que cada actualización que realiza en la base de datos es correcta. Solo entonces el puente liberará los fondos o retiros que deben ser procesados.
El último es la anticensura, que en última instancia puede atribuirse al atributo de actividad. Si todo el sistema falla, ¿alguien viene y propone una actualización de la base de datos, que luego es manejada por el puente?
En resumen, cuando consideramos la seguridad del resumen, en realidad se considera desde la perspectiva del contrato inteligente en Ethereum, es decir, el contrato puente, y el puente debe asegurarse de que cada actualización de la base de datos sea correcta. No se trata realmente de una web descentralizada. Nuestra verdadera preocupación debería ser esta parte honesta que ayuda a salvar la seguridad de los activos bloqueados.
Franci: En uno de tus artículos, hiciste una metáfora, comparando a Gandalf en la película "El señor de los anillos" con una fiesta honesta contra los malhechores. Para el lado honesto de esto, ¿puedes explicar un poco más?
Patrick: Gandalf es un gran ejemplo, porque en esta escena, en realidad está parado en un puente y dice: "No puedes pasar". Luego destruye el puente y el oponente se cae. Era el lateral honesto, daba un paso al frente y protegía a sus compañeros. La situación es exactamente la misma aquí. El contrato puente es en última instancia responsable de asegurar los activos bloqueados en este sistema fuera de la cadena. El lado honesto es un compinche, y Gandalf es el compinche del equipo para asegurarse de que el anillo pueda ser destruido. Y la parte honesta está ayudando a cerrar el contrato. Debido a que estos contratos se implementan en Ethereum, en realidad no pueden interactuar con el mundo exterior. Entonces necesitan a alguien que mire el sistema fuera de la cadena, y eso es lo que hace la parte honesta.
Franci: Como dijiste, Arbitrum está utilizando un sistema a prueba de fraude, por lo que ya asumen que hay una parte honesta. Entonces, ¿qué pasa con otros tipos de paquetes acumulativos? ¿Quién es la única parte honesta en un zk-Rollup usando pruebas de validez?
Patrick: Como mencionamos anteriormente, el contrato puente es responsable de verificar cada actualización aplicada a la base de datos. Bueno, una parte honesta, un relevo o cualquiera puede enviar una actualización de la base de datos al puente, pero al mismo tiempo también debe proporcionar pruebas de que esta actualización de la base de datos es correcta. Y eso es lo que hacemos. Solo queremos que el contrato inteligente crea que las actualizaciones de la base de datos son válidas, correctas y deben aceptarse y procesarse.
Hay dos formas de hacer esto, usando dos tipos diferentes de evidencia. Una es la prueba de fraude utilizada actualmente por Arbitrum: cualquiera puede venir y enviar una actualización potencial al puente y también verificarla. Luego habrá unas dos semanas en las que cualquiera puede venir y desafiarlo. Cuando alguien inicia un desafío, el puente coordinará este mecanismo de juego a prueba de fraude, moviéndose de un lado a otro hasta que encuentre una transición de estado muy pequeña en la que no estemos de acuerdo. Luego, el puente verificará de forma independiente para averiguar quién tiene la culpa. Así es como funcionan los sistemas a prueba de fraude. Su desventaja es que hay un período de desafío de dos o una semana, porque debe brindar suficiente tiempo para que los desafiantes se levanten y protejan el sistema.
En cuanto al sistema de prueba de validez, el mecanismo utilizado por zk-Rollup, como Starknet, zkSync, Polygon Hermez, Scroll, Taiko, etc. Cuando los usuarios u operadores envían actualizaciones de la base de datos al puente, también proporcionan una prueba de validez. Esta es una prueba matemática, más allá de toda duda razonable, y muestra que esta actualización de la base de datos es correcta y válida. Esta es una propiedad muy poderosa porque cualquiera puede enviar una actualización con una prueba al puente, y el puente puede confiar inmediatamente en que la actualización es correcta y válida y procesarla.
Estos son dos enfoques diferentes, cada uno con pros y contras. Pero nuevamente, solo abordan esa pregunta: ¿Son correctas las actualizaciones de la base de datos? Eso es todo. Hay otros problemas que deben abordarse, como problemas de censura, problemas de disponibilidad de datos y más.
Cómo descentralizar Rollup y la adopción del esquema de gobierno DAO
Franci: Todavía hay muchas partes de confianza y autorizadas en el sistema Rollup ¿Cómo ve el proceso de rollup descentralizado? ¿Cuál cree que es el objetivo más importante y qué parte de él necesitamos descentralizar con mayor urgencia?
Patrick: Volvamos al ejemplo de intercambio centralizado mencionado anteriormente para pensar en este tema. Al igual que los intercambios centralizados, en realidad hay un clasificador detrás de ellos. Por ejemplo, si inicio sesión en el sitio web de Coinbase para enviar una transacción, su clasificador aceptará mi transacción y la clasificará. Estas transacciones luego se pasan al servidor, donde son procesadas y actualizadas por la base de datos. Esa es la arquitectura actual de estos intercambios, que está muy centralizada. Durante todo el proceso, no sabemos qué pasó en esta caja negra. Tenemos que confiar completamente en esta entidad para proteger miles de millones de dólares y, básicamente, confiar en los procesos humanos para hacerlo. Esto es malo.
No queremos depender de los humanos porque los humanos no son buenos para hacer cumplir las reglas. Entonces, en el lado del resumen, lo que realmente estamos tratando de hacer es tratar de replicar esa arquitectura, pero al mismo tiempo hacerla más transparente y auditable. Esto significa que cada uno de nosotros puede comprobar que funciona correctamente. Confiamos en el software para hacer cumplir las reglas, no en los humanos.
En base a estos antecedentes, debemos preocuparnos por dos aspectos. El primero es el clasificador, su único trabajo es tener un sitio web, interfaz o API orientado al usuario, aceptar transacciones de usuario y decidir el orden de ejecución, y luego pasar las transacciones clasificadas a la siguiente parte. Pueden enviar la transacción directamente al contrato inteligente puente en Ethereum, o pueden pasar la presidencia a un grupo de ejecutores. El ejecutor acepta las transacciones, las ejecuta en orden, crea una actualización de la base de datos y finalmente propone la actualización al puente.
Bueno, con estos tres actores diferentes, ahora viene la discusión real de qué es la descentralización. Como ya mencioné, para un resumen solo debemos asumir que hay una persona honesta que puede proteger el sistema. La pregunta entonces es, ¿quién actúa como esta parte honesta? ¿Es un clasificador o un ejecutor?
Una de las ventajas del resumen es que el ordenante que acepta las transacciones de los usuarios es opcional. En realidad, no necesita un secuenciador, es solo una buena promesa de obtener reconocimientos instantáneos para una buena experiencia de usuario. La razón de esto es que el contrato puente en Ethereum es el pedido que es responsable en última instancia de finalizar las transacciones. Es decir, cualquier usuario o cualquier contrato inteligente puede enviar transacciones que quiera ejecutar en el sistema o en el sistema fuera de la cadena directamente al puente. Después de que el puente recibe la transacción, eventualmente la ordenará y la ejecutará. Entonces, lo bueno es que, dado que podemos confiar en que el contrato puente siempre hará lo correcto, no nos importa lo que le suceda al ordenante. Por lo tanto, se confía en los clasificadores, pero son opcionales. Existen solo para proporcionar una buena experiencia de usuario, no para proteger realmente el sistema. Simplemente brindan una promesa en qué orden se ejecutarán las transacciones, pero no ninguna garantía.
Es entonces el trabajo del siguiente actor, quien acepta y ejecuta la transacción, y luego propone una actualización de estado del puente. Así que esto necesita hablar de tres niveles de finalidad. Solo después de que las transacciones se secuencian y ejecutan en ese orden, el puente toma medidas, por ejemplo, permitiendo a los usuarios retirar sus fondos.
Volviendo a la pregunta original, ¿quién actúa como parte honesta? Según lo dicho antes, el clasificador no tiene por qué ser honesto. Además, no necesariamente necesita un gran grupo de clasificadores, puede ser uno, tres, cinco.
Los ejecutores encargados de ejecutar las transacciones son la descentralización de la que debemos preocuparnos. Pero la descentralización aquí es muy diferente de la forma en que pensamos en la capa 1. Realmente no queremos maximizar la cantidad de participantes activos en un resumen. Hay 500.000 participantes en la capa del protocolo Ethereum. En rollup no se requieren tantas personas para ser albaceas, porque lo que realmente necesitamos es una parte honesta. Entonces, la descentralización realmente está diciendo, ¿puede el sistema ser lo suficientemente abierto como para permitir que una persona honesta intensifique y proteja el sistema? Sin gastar tanto recursos.
La segunda parte de la descentralización se trata de cómo gobernar la red. ¿Cómo podemos participar colectivamente en la decisión de cómo se debe actualizar el sistema? Incluyendo actualizaciones de software para contratos inteligentes y actualizaciones de componentes fuera de la cadena. ¿Cómo llega la comunidad a un consenso sobre esto? Esa es una esfera completamente diferente de discusión sobre la descentralización. Esto es más un problema de gobernabilidad. ¿Cómo gestionamos este sistema? Aquí es probablemente donde desea maximizar el compromiso.
Entonces, para resumir, hay dos aspectos en la descentralización. La descentralización de los sistemas en tiempo real requiere solo una parte honesta o un ejecutor honesto. Esa es la línea de base de suposición básica que buscamos. Luego tenemos cosas sobre el gobierno del sistema y el gobierno de las actualizaciones de software, donde se pueden usar los DAO, y aquí está la parte que requiere intervención humana. A veces necesitamos humanos para decidir sobre las escaladas, y esto requiere un DAO o alguna forma de lograr un consenso sobre esto, maximizando la gobernanza de los participantes.
Franci: Entonces, en términos de gobernanza, ¿cree que eliminar las claves de actualización es el objetivo final de la gobernanza descentralizada?
Patrick: Démosle a la audiencia un poco de historia primero. Por ejemplo, cuando necesitamos considerar la implementación en tiempo real de un determinado sistema, nos enfrentaremos a un problema: ¿cómo realizar la actualización? Una es que puede haber una clave de administrador, suponiendo que haya un administrador allí, tienen acceso exclusivo para actualizar el contrato inteligente como mejor les parezca. El segundo método es más como una firma múltiple. En lugar de confiar en una sola entidad, podemos confiar en 5/9 o 9/12 firmas múltiples. Luego, el tercer enfoque, que es exclusivo de estos sistemas acumulativos (Arbitrum usa este enfoque), introduce un componente de gobernanza en cadena. ¿Se podría presentar un DAO de titulares de tokens completos, potencialmente miles de personas, para llegar a un consenso sobre cómo actualizar el sistema? Una vez que tenga un DAO, se pueden tomar decisiones sobre actualizaciones y se pueden tomar decisiones sobre diferentes tipos de delegación. Por ejemplo, tal vez el DAO sea el responsable final de autorizar las actualizaciones del sistema, pero también podría designar un comité de seguridad (multisig el 12 de septiembre) que podría intervenir en caso de emergencia para actualizar y asegurar el sistema, y corregir errores muy rápidamente
Lo realmente bueno de todo este proceso es que es transparente, cualquiera puede ver estas capas de autorización y, por supuesto, las responsabilidades de cada parte. Entonces, para responder a su pregunta, no creo que debamos eliminar la clave de administrador. Creo que es importante que el proceso sea transparente y que la DAO que gestiona la gobernanza o la forma de gobernanza que finalmente se aplica permita que la comunidad llegue a un consenso. Porque creo que cuando consideramos el paquete acumulativo como una pila de software, el 99,99999 % de las veces, el software se ejecutará de forma autónoma y aplicará reglas para proteger a los usuarios de la red. Esto es cierto la mayor parte del tiempo. Luego, el 0,000001 % del tiempo, se requiere algún tipo de intervención humana. Haga una sugerencia para actualizar el software o intervenga y corrija el error a tiempo. En realidad, esto no es tan diferente de algo como Bitcoin o Ethereum.
La única diferencia es que este proceso de gestión y los responsables son claros y muy transparentes. Sabemos exactamente quién debe intervenir en el momento adecuado y hacer lo correcto. Mientras que en Bitcoin y Ethereum, se basan más en un consenso aproximado. Realmente no quieren definir el proceso porque quieren defenderse de los ataques a la gobernabilidad. Ha habido un reciente bloqueo parcial de PoS en Ethereum. Debido a algunos errores en el cliente de Prysm, el dispositivo de finalidad no funcionaba. Así que Prysm tuvo que salir y corregir su error y volver a implementar. Entonces, incluso en estas redes en capas en tiempo real, a veces nos encontramos con lugares donde se requiere la intervención humana para proteger el sistema. Creo que esto también es necesario para el resumen. Pero necesitamos tener algunos procedimientos efectivos para saber quién tiene la autoridad y responsabilizarlos por el sistema de acumulación.
La transcripción de esta entrevista se transcribió con la ayuda de OpenAI Whisper y se compiló sobre esta base.
Enlace GitHub:
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Conversación con el investigador de Arbitrum Patrick McCorry | ¿Cómo descentralizar Rollup?
Introducción
Cuando observamos la visión y la hoja de ruta de varias soluciones de Rollup, encontraremos que casi todos los Rollup tienen un objetivo final. Si este objetivo se condensa en una oración: construir una pila de tecnología, proporcionarla a la comunidad, resolver La expansión de la blockchain y, en última instancia, la descentralización de la pila tecnológica de operaciones y gobernanza. Esto lleva al término resumen descentralizado.
Entonces, ¿qué es exactamente la descentralización? ¿Cuál es la división del trabajo entre las distintas partes del sistema Rollup? ¿La descentralización significa maximizar los participantes en la operación del sistema? ¿Qué impacto tendrá un clasificador centralizado? ¿Cómo se debe diseñar el ordenamiento compartido y el consenso local L2? ¿Cuál es la función del probador único en ZK-Rollup? ¿Cómo sería una red de probadores abierta y descentralizada? ¿Por qué necesitamos la aceleración de hardware zk? ¿Cuál es la solución al problema de disponibilidad de datos? ....
Hay discusiones interminables sobre el resumen descentralizado en la comunidad, por lo que ECN seleccionó una serie de entrevistas de podcast con el tema "Resumen descentralizado" e invitó a fundadores e investigadores destacados en este campo para hablar sobre su comprensión del resumen descentralizado.
El primer número invitó a Patrick McCorry, investigador de la Fundación Arbitrum.Este episodio sirve como un resumen de la serie, hablando principalmente sobre los problemas que la capa 2 quiere resolver, el significado del resumen descentralizado, cómo entender sus atributos de seguridad y cómo Gobernanza DAO Funciona en rollup descentralizado.
Invitado de este episodio: Patrick McCorry, twitter @stonecoldpat0
Moderador: Franci, twitter@FrancixDeng
Remolque
Fase 2: Secuenciador Compartido y Consenso L2
Problema 3: Prover network y aceleración de hardware zk
Problema 4: Disponibilidad de datos y almacenamiento descentralizado
Escuchar
Haga clic para suscribirse al podcast para obtener más información:
YouTube:
Microcosmo:
Marca de tiempo
01:49 Introducción a los antecedentes personales de Patrick McCorry
03:26 ¿Por qué existe la capa 2 y qué intenta resolver?
11:56 ¿Qué armas están usando para mantener seguros a los usuarios?
14:40 Qué significa la seguridad y vivacidad de Rollup
17:47 Explicar la seguridad del resumen desde la disponibilidad de datos, la validez de la transición de estado y la anticensura
19:45 El papel de la única entidad honesta, ¿quién actúa como la única entidad honesta acumulada?
28:47 ¿Qué opinas del resumen descentralizado? ¿Cuál es el objetivo más apremiante en este momento?
37:21 La importancia de la gobernanza de DAO en un resumen descentralizado
Sección de entrevistas
Problemas que Layer2 quiere resolver
Franci: Lo que vamos a explorar en este episodio es, ¿qué significa tener un Rollup descentralizado? Por qué es importante ¿Qué problema están tratando de resolver? Espero que a través de esta charla, los lectores y oyentes finalmente puedan comprender qué es un resumen descentralizado real y qué objetivos deben cumplir. Deje que nuestro invitado, Patrick McCorry, se presente.
patricio: hola a todos Creo que por experiencia, estoy sesgado hacia la investigación académica. De 2013 a 2016, mi dirección doctoral estuvo relacionada con Bitcoin y Ethereum. Luego, desde 2016 hasta alrededor de 2019, fui investigador en universidades como UCL, King's College London y UIUC. Durante este tiempo, he estado muy interesado en los protocolos de Capa 2. Incluye Bitcoin Lightning Network, plasma y, por supuesto, Rollup. Entonces, en 2019, intenté hacer una startup. Luego dejé la universidad, mi amigo y yo, básicamente dos personas y un perro. Estamos tratando de ser una empresa nueva enfocada en la capa 2. Pero era un mercado bajista y luego fuimos adquiridos por Infura. Luego dejé Infura y recientemente me uní a la Fundación Arbitrum. Así que volví a centrarme en la investigación acumulada a tiempo completo. Durante todo este período, me he centrado principalmente en la educación, explicando por qué debemos preocuparnos por los protocolos de capa 2.
Franci: Comencemos con los temas más básicos. En general, ¿qué es un sistema L2? ¿Qué significa cuando un usuario deposita dinero en el sistema L2 y realiza una transacción allí?
Patrick: Hablando de este tema, creo que debemos dar un paso atrás y pensar, ¿cuál es el punto de blockchain? ¿Cuál es el punto de todos estos sistemas que estamos tratando de construir? Una vez que tengamos esto en cuenta, tiene un poco más de sentido explicar L2. Lo real detrás de una red blockchain como Bitcoin o Ethereum es solo una base de datos. es una base de datos pública en la que cualquiera puede leer y escribir. Por lo tanto, es una base de datos de saldos de cuentas y, por supuesto, en Ethereum, hay varios programas además de los saldos de cuentas. Entonces puedo implementar mi código en la base de datos. Mi programa puede tener algún estado y puedo hacer transacciones en él, y todos pueden ver las actualizaciones de la base de datos. Fundamentalmente, solo estamos tratando con bases de datos. Suena aburrido.
Y la importancia de la cadena de bloques en sí misma, en realidad es solo una pista de auditoría. Por lo tanto, almacena una lista de transacciones y, si le doy una copia de la cadena de bloques, puede volver a calcular esta base de datos usted mismo. Fundamentalmente, estamos construyendo una base de datos pública que cualquiera puede leer, calcular y escribir de forma independiente. Bueno, esta es la capa 1.
Ya sea la capa 1 de Bitcoin o Ethereum, el problema es que necesita maximizar la descentralización. Hay tres formas diferentes de pensar en la descentralización. Uno es el operador: quien maneja la red, quien produce bloques, quien confirma las transacciones. Con muchas de estas redes, siempre queremos maximizar la posibilidad de que cualquiera pueda participar en el proceso. De esta manera no hay un único punto de falla. Por otro lado, también debe considerar quién puede verificar cada actualización de la base de datos, quién puede verificar que los operadores estén haciendo su trabajo, que la base de datos sea correcta y si hay otros problemas. Sus trabajos y bases de datos son correctos y válidos en todo momento. En este punto, tendrás este problema. Desea maximizar la cantidad de personas que participan en la validación de la red y desea maximizar la cantidad de personas que ejecutan la red. Entonces, es algo así como la vieja pelea por el tamaño del bloque de Bitcoin. Actualice los bloques y podrá procesar más transacciones. Pero luego será más difícil, porque necesita requisitos de hardware más altos para verificar la red en tiempo real y finalmente convertirse en un operador de red. Esta es la cuestión de cómo considerar la descentralización a nivel de capa1. El tercer aspecto es hacerlo asequible. Si pagamos $200 para realizar transacciones en una red, ¿realmente está descentralizada? Aparentemente no lo es. Por lo tanto, en cierto sentido, este es un problema de trilema remanente de la historia.
Durante mucho tiempo, estuvimos atrapados en este trilema, porque si intenta procesar más transacciones, una de las partes se verá perjudicada de alguna manera, ya sea que aumenten las tarifas, aumenten los requisitos de hardware o se convierta en un problema. operativa más difícil. Esta es una discusión sobre la descentralización en el contexto de L1.
Franci: Como dijiste, los usuarios considerarán el costo de las transacciones. Entonces podrían optar por depositar su dinero en un intercambio centralizado. Hablando en términos generales, ¿es esto una especie de L2?
Patrick: Creo que es una buena manera de pensar en términos de intercambios. Un intercambio centralizado es como una base de datos. Pero el problema es que es una base de datos privada. Entonces, básicamente, la base de datos del intercambio, solo puede leer y escribir. Y usuarios como usted y yo, no podemos auditar esta base de datos, no podemos verificar que sea correcta. Pero la ventaja de operar en una bolsa es que es muy barato. El propósito del sistema de cadena de bloques L1 es estar lo más descentralizado posible, pero el costo es demasiado alto.
Entonces, cuando pensamos en el mundo L2, en el mundo L2, realmente no queremos recrear el L1. Realmente no queremos tener que construir una red descentralizada que maximice la cantidad de participantes. Porque ya sabemos que, históricamente, ha sido muy difícil construir este tipo de sistemas y hacerlos escalar mucho en términos de rendimiento. Entonces pensaríamos, ¿podemos construir un sistema que se parezca a un intercambio, pero aún conserva las propiedades de un sistema de cadena de bloques, donde la base de datos es pública? Cualquiera puede leer la base de datos, cualquiera puede escribir en ella y cualquiera puede protegerla. Este es el objetivo de L2.
Cuando empiezas a comparar intercambios con lo que hemos construido en L2, al final del día estamos comparando cosas de ingeniería de puentes. El puente del que hablo es que habrá un contrato inteligente en Ethereum, y bloqueo los activos en este contrato inteligente llamado "puente". Una vez bloqueado en el puente, aparecerá en otras bases de datos. Esta base de datos podría ser Coinbase, podría ser Arbitrum, podría ser Optimism. Entonces la pregunta es, cuando quiero sacar mis fondos de esta otra base de datos y devolverlos a Ethereum, ¿cómo me autorizan y cómo convenzo al puente para que desbloquee los fondos?
Para Coinbase, el usuario confía en Coinbase para autorizar el retiro, el contrato inteligente verificará y dirá, oh, Coinbase autorizado, puedo retirar los fondos. Pero para L2, la atención se centra en el puente y cómo hacer creer que esta base de datos fuera de la cadena es segura y luego permitir que se desbloqueen los fondos.
Entonces, volviendo a tu pregunta original. Creo que Coinbase o estos intercambios son básicamente lo que queremos construir para L2. Pero queremos construirlo de una manera que proteja a los usuarios. Si Coinbase deja de funcionar, o si hacen algo malo y son pirateados, los usuarios siempre están seguros y protegidos. No tienen que confiar en los operadores del sistema. En lo que realmente se enfoca es en cómo los activos se bloquean en el puente del sistema y luego se sacan de ese sistema.
Cómo definir un Rollup seguro y descentralizado
Franci: Entonces, lo que tiene que hacer Rollup es elegir algún compromiso entre estos. ¿Qué armas utilizan para mantener seguros a los usuarios?
Patrick: Creo que el enfoque real está en el puente mismo. Por ejemplo, el puente de Arbitrum, que es un conjunto de contratos inteligentes implementados en Ethereum. El puente actualmente tiene alrededor de $ 6 mil millones más o menos. En realidad, es un conjunto de contratos inteligentes en Ethereum con $ 6 mil millones. Debe convencer al puente de que tengo derecho a retirar mis fondos del puente y devolverlos a Ethereum.
Entonces, ¿qué armas tenemos para mantener seguros a los usuarios? Una de las cosas buenas de estar en L2 es que podemos hacer una muy buena suposición. Podemos suponer que ya existe un L1, como Bitcoin o Ethereum, que ya existe y se está ejecutando. Podemos suponer que ya existe esta plataforma descentralizada y construir sobre ella. Y piense en esta plataforma como un tercero de confianza, confíe en este tercero y garantice que siempre haremos lo correcto. Esa es la base de todos estos sistemas. Si tiene una buena plataforma descentralizada, aproveche y reutilice y construya sobre ella.
Entonces, la declaración del problema en realidad se convierte en, ahora tenemos esta base de datos fuera de la cadena que registra los saldos de las cuentas y los estados del programa. ¿Podemos usar un tercero de confianza para verificar que cada actualización de esta base de datos sea correcta y válida? De esto se trata realmente L2. Para dar un ejemplo concreto, digamos que en la base de datos de Arbitrum hay saldos de cuentas, estados de programas y luego el contrato inteligente de Arbitrum es un tercero confiable que garantiza que el puente siempre funcionará correctamente. Las personas que manejan la red de Arbitrum, los ordenantes, los validadores, envían periódicamente puntos de control o pruebas al puente para convencerlo de que las actualizaciones aplicadas a la base de datos son correctas y válidas. Si el puente está convencido, permitirá a los usuarios retirar sus fondos de Arbitrum. Así que esta es nuestra arma.
Franci: Acabas de decir que Rollup está construido sobre Ethereum. Esto me recuerda un dicho que la comunidad siempre dice que Rollup hereda la seguridad de Ethereum. Entonces, ¿significa esto que la seguridad de Rollup es equivalente a la de Ethereum?
Patrick: Creo que es una buena forma de pensar en ello. La respuesta es sí y no. Creo que hay diferentes maneras de pensar sobre esto. La forma más fácil es la seguridad y la vitalidad. En términos de seguridad, solo consideramos este problema en la base de datos, lo que significa que cada actualización de la base de datos es válida. Es imposible tener una actualización no válida, porque si hay una actualización no válida en la base de datos, puede robar los activos. Esto rompe la seguridad básica. Y eso es una gran parte de eso.
La siguiente parte es la vitalidad, lo que significa que podemos asegurarnos de que las personas puedan realizar actualizaciones en la base de datos. En una base de datos, para mantenerla viva, necesitamos garantizar, ¿siempre podemos actualizarla? ¿O hay un lado honesto? Pueden proponer una actualización, que finalmente se procesa. Esto es importante porque si Coinbase o Kraken fallan o hacen algo malo, sus fondos se estancarán. Ahí es donde es ligeramente diferente de Ethereum porque en Ethereum tienes que confiar en el PoS y en la mayoría honesta para mantener vivo el sistema. Mientras que en el resumen, ya asumimos que esta actividad se ha obtenido de forma gratuita de Ethereum. Solo tenemos que asumir que hay una fiesta honesta por ahí. Mientras haya una persona honesta dispuesta a hacer el trabajo y proponer actualizaciones a la base de datos, entonces, por supuesto, el sistema seguirá vivo. A esto nos referimos con heredar la seguridad de Ethereum.
Entonces, cuando pensamos en la seguridad de los paquetes acumulativos, en realidad no estamos pensando en una red descentralizada. Puede haber una red acumulada descentralizada, pero eso no importa. La seguridad de Rollup realmente depende de su contrato inteligente como puente, y debe convencerse de tres aspectos.
El primero es un problema de disponibilidad de datos: el puente cree que cualquier persona en el mundo puede acceder a la base de datos y cualquiera puede volver a calcular una copia de la base de datos y la copia más reciente. Así que esto es lo primero que tienes que convencer al puente. ¿Puede alguien en el mundo acceder a una copia de la base de datos que nos interesa?
La segunda propiedad, podría llamarla el problema de integridad de transición de estado, y esto se remonta al tema de la seguridad. El puente necesita confiar en que cada actualización de la base de datos sea correcta y válida. Y esto es para garantizar que nadie pueda robar sus fondos. Por lo tanto, el operador de acumulación tiene que convencer periódicamente al puente de que cada actualización que realiza en la base de datos es correcta. Solo entonces el puente liberará los fondos o retiros que deben ser procesados.
El último es la anticensura, que en última instancia puede atribuirse al atributo de actividad. Si todo el sistema falla, ¿alguien viene y propone una actualización de la base de datos, que luego es manejada por el puente?
En resumen, cuando consideramos la seguridad del resumen, en realidad se considera desde la perspectiva del contrato inteligente en Ethereum, es decir, el contrato puente, y el puente debe asegurarse de que cada actualización de la base de datos sea correcta. No se trata realmente de una web descentralizada. Nuestra verdadera preocupación debería ser esta parte honesta que ayuda a salvar la seguridad de los activos bloqueados.
Franci: En uno de tus artículos, hiciste una metáfora, comparando a Gandalf en la película "El señor de los anillos" con una fiesta honesta contra los malhechores. Para el lado honesto de esto, ¿puedes explicar un poco más?
Patrick: Gandalf es un gran ejemplo, porque en esta escena, en realidad está parado en un puente y dice: "No puedes pasar". Luego destruye el puente y el oponente se cae. Era el lateral honesto, daba un paso al frente y protegía a sus compañeros. La situación es exactamente la misma aquí. El contrato puente es en última instancia responsable de asegurar los activos bloqueados en este sistema fuera de la cadena. El lado honesto es un compinche, y Gandalf es el compinche del equipo para asegurarse de que el anillo pueda ser destruido. Y la parte honesta está ayudando a cerrar el contrato. Debido a que estos contratos se implementan en Ethereum, en realidad no pueden interactuar con el mundo exterior. Entonces necesitan a alguien que mire el sistema fuera de la cadena, y eso es lo que hace la parte honesta.
Franci: Como dijiste, Arbitrum está utilizando un sistema a prueba de fraude, por lo que ya asumen que hay una parte honesta. Entonces, ¿qué pasa con otros tipos de paquetes acumulativos? ¿Quién es la única parte honesta en un zk-Rollup usando pruebas de validez?
Patrick: Como mencionamos anteriormente, el contrato puente es responsable de verificar cada actualización aplicada a la base de datos. Bueno, una parte honesta, un relevo o cualquiera puede enviar una actualización de la base de datos al puente, pero al mismo tiempo también debe proporcionar pruebas de que esta actualización de la base de datos es correcta. Y eso es lo que hacemos. Solo queremos que el contrato inteligente crea que las actualizaciones de la base de datos son válidas, correctas y deben aceptarse y procesarse.
Hay dos formas de hacer esto, usando dos tipos diferentes de evidencia. Una es la prueba de fraude utilizada actualmente por Arbitrum: cualquiera puede venir y enviar una actualización potencial al puente y también verificarla. Luego habrá unas dos semanas en las que cualquiera puede venir y desafiarlo. Cuando alguien inicia un desafío, el puente coordinará este mecanismo de juego a prueba de fraude, moviéndose de un lado a otro hasta que encuentre una transición de estado muy pequeña en la que no estemos de acuerdo. Luego, el puente verificará de forma independiente para averiguar quién tiene la culpa. Así es como funcionan los sistemas a prueba de fraude. Su desventaja es que hay un período de desafío de dos o una semana, porque debe brindar suficiente tiempo para que los desafiantes se levanten y protejan el sistema.
En cuanto al sistema de prueba de validez, el mecanismo utilizado por zk-Rollup, como Starknet, zkSync, Polygon Hermez, Scroll, Taiko, etc. Cuando los usuarios u operadores envían actualizaciones de la base de datos al puente, también proporcionan una prueba de validez. Esta es una prueba matemática, más allá de toda duda razonable, y muestra que esta actualización de la base de datos es correcta y válida. Esta es una propiedad muy poderosa porque cualquiera puede enviar una actualización con una prueba al puente, y el puente puede confiar inmediatamente en que la actualización es correcta y válida y procesarla.
Estos son dos enfoques diferentes, cada uno con pros y contras. Pero nuevamente, solo abordan esa pregunta: ¿Son correctas las actualizaciones de la base de datos? Eso es todo. Hay otros problemas que deben abordarse, como problemas de censura, problemas de disponibilidad de datos y más.
Cómo descentralizar Rollup y la adopción del esquema de gobierno DAO
Franci: Todavía hay muchas partes de confianza y autorizadas en el sistema Rollup ¿Cómo ve el proceso de rollup descentralizado? ¿Cuál cree que es el objetivo más importante y qué parte de él necesitamos descentralizar con mayor urgencia?
Patrick: Volvamos al ejemplo de intercambio centralizado mencionado anteriormente para pensar en este tema. Al igual que los intercambios centralizados, en realidad hay un clasificador detrás de ellos. Por ejemplo, si inicio sesión en el sitio web de Coinbase para enviar una transacción, su clasificador aceptará mi transacción y la clasificará. Estas transacciones luego se pasan al servidor, donde son procesadas y actualizadas por la base de datos. Esa es la arquitectura actual de estos intercambios, que está muy centralizada. Durante todo el proceso, no sabemos qué pasó en esta caja negra. Tenemos que confiar completamente en esta entidad para proteger miles de millones de dólares y, básicamente, confiar en los procesos humanos para hacerlo. Esto es malo.
No queremos depender de los humanos porque los humanos no son buenos para hacer cumplir las reglas. Entonces, en el lado del resumen, lo que realmente estamos tratando de hacer es tratar de replicar esa arquitectura, pero al mismo tiempo hacerla más transparente y auditable. Esto significa que cada uno de nosotros puede comprobar que funciona correctamente. Confiamos en el software para hacer cumplir las reglas, no en los humanos.
En base a estos antecedentes, debemos preocuparnos por dos aspectos. El primero es el clasificador, su único trabajo es tener un sitio web, interfaz o API orientado al usuario, aceptar transacciones de usuario y decidir el orden de ejecución, y luego pasar las transacciones clasificadas a la siguiente parte. Pueden enviar la transacción directamente al contrato inteligente puente en Ethereum, o pueden pasar la presidencia a un grupo de ejecutores. El ejecutor acepta las transacciones, las ejecuta en orden, crea una actualización de la base de datos y finalmente propone la actualización al puente.
Bueno, con estos tres actores diferentes, ahora viene la discusión real de qué es la descentralización. Como ya mencioné, para un resumen solo debemos asumir que hay una persona honesta que puede proteger el sistema. La pregunta entonces es, ¿quién actúa como esta parte honesta? ¿Es un clasificador o un ejecutor?
Una de las ventajas del resumen es que el ordenante que acepta las transacciones de los usuarios es opcional. En realidad, no necesita un secuenciador, es solo una buena promesa de obtener reconocimientos instantáneos para una buena experiencia de usuario. La razón de esto es que el contrato puente en Ethereum es el pedido que es responsable en última instancia de finalizar las transacciones. Es decir, cualquier usuario o cualquier contrato inteligente puede enviar transacciones que quiera ejecutar en el sistema o en el sistema fuera de la cadena directamente al puente. Después de que el puente recibe la transacción, eventualmente la ordenará y la ejecutará. Entonces, lo bueno es que, dado que podemos confiar en que el contrato puente siempre hará lo correcto, no nos importa lo que le suceda al ordenante. Por lo tanto, se confía en los clasificadores, pero son opcionales. Existen solo para proporcionar una buena experiencia de usuario, no para proteger realmente el sistema. Simplemente brindan una promesa en qué orden se ejecutarán las transacciones, pero no ninguna garantía.
Es entonces el trabajo del siguiente actor, quien acepta y ejecuta la transacción, y luego propone una actualización de estado del puente. Así que esto necesita hablar de tres niveles de finalidad. Solo después de que las transacciones se secuencian y ejecutan en ese orden, el puente toma medidas, por ejemplo, permitiendo a los usuarios retirar sus fondos.
Volviendo a la pregunta original, ¿quién actúa como parte honesta? Según lo dicho antes, el clasificador no tiene por qué ser honesto. Además, no necesariamente necesita un gran grupo de clasificadores, puede ser uno, tres, cinco.
Los ejecutores encargados de ejecutar las transacciones son la descentralización de la que debemos preocuparnos. Pero la descentralización aquí es muy diferente de la forma en que pensamos en la capa 1. Realmente no queremos maximizar la cantidad de participantes activos en un resumen. Hay 500.000 participantes en la capa del protocolo Ethereum. En rollup no se requieren tantas personas para ser albaceas, porque lo que realmente necesitamos es una parte honesta. Entonces, la descentralización realmente está diciendo, ¿puede el sistema ser lo suficientemente abierto como para permitir que una persona honesta intensifique y proteja el sistema? Sin gastar tanto recursos.
La segunda parte de la descentralización se trata de cómo gobernar la red. ¿Cómo podemos participar colectivamente en la decisión de cómo se debe actualizar el sistema? Incluyendo actualizaciones de software para contratos inteligentes y actualizaciones de componentes fuera de la cadena. ¿Cómo llega la comunidad a un consenso sobre esto? Esa es una esfera completamente diferente de discusión sobre la descentralización. Esto es más un problema de gobernabilidad. ¿Cómo gestionamos este sistema? Aquí es probablemente donde desea maximizar el compromiso.
Entonces, para resumir, hay dos aspectos en la descentralización. La descentralización de los sistemas en tiempo real requiere solo una parte honesta o un ejecutor honesto. Esa es la línea de base de suposición básica que buscamos. Luego tenemos cosas sobre el gobierno del sistema y el gobierno de las actualizaciones de software, donde se pueden usar los DAO, y aquí está la parte que requiere intervención humana. A veces necesitamos humanos para decidir sobre las escaladas, y esto requiere un DAO o alguna forma de lograr un consenso sobre esto, maximizando la gobernanza de los participantes.
Franci: Entonces, en términos de gobernanza, ¿cree que eliminar las claves de actualización es el objetivo final de la gobernanza descentralizada?
Patrick: Démosle a la audiencia un poco de historia primero. Por ejemplo, cuando necesitamos considerar la implementación en tiempo real de un determinado sistema, nos enfrentaremos a un problema: ¿cómo realizar la actualización? Una es que puede haber una clave de administrador, suponiendo que haya un administrador allí, tienen acceso exclusivo para actualizar el contrato inteligente como mejor les parezca. El segundo método es más como una firma múltiple. En lugar de confiar en una sola entidad, podemos confiar en 5/9 o 9/12 firmas múltiples. Luego, el tercer enfoque, que es exclusivo de estos sistemas acumulativos (Arbitrum usa este enfoque), introduce un componente de gobernanza en cadena. ¿Se podría presentar un DAO de titulares de tokens completos, potencialmente miles de personas, para llegar a un consenso sobre cómo actualizar el sistema? Una vez que tenga un DAO, se pueden tomar decisiones sobre actualizaciones y se pueden tomar decisiones sobre diferentes tipos de delegación. Por ejemplo, tal vez el DAO sea el responsable final de autorizar las actualizaciones del sistema, pero también podría designar un comité de seguridad (multisig el 12 de septiembre) que podría intervenir en caso de emergencia para actualizar y asegurar el sistema, y corregir errores muy rápidamente
Lo realmente bueno de todo este proceso es que es transparente, cualquiera puede ver estas capas de autorización y, por supuesto, las responsabilidades de cada parte. Entonces, para responder a su pregunta, no creo que debamos eliminar la clave de administrador. Creo que es importante que el proceso sea transparente y que la DAO que gestiona la gobernanza o la forma de gobernanza que finalmente se aplica permita que la comunidad llegue a un consenso. Porque creo que cuando consideramos el paquete acumulativo como una pila de software, el 99,99999 % de las veces, el software se ejecutará de forma autónoma y aplicará reglas para proteger a los usuarios de la red. Esto es cierto la mayor parte del tiempo. Luego, el 0,000001 % del tiempo, se requiere algún tipo de intervención humana. Haga una sugerencia para actualizar el software o intervenga y corrija el error a tiempo. En realidad, esto no es tan diferente de algo como Bitcoin o Ethereum.
La única diferencia es que este proceso de gestión y los responsables son claros y muy transparentes. Sabemos exactamente quién debe intervenir en el momento adecuado y hacer lo correcto. Mientras que en Bitcoin y Ethereum, se basan más en un consenso aproximado. Realmente no quieren definir el proceso porque quieren defenderse de los ataques a la gobernabilidad. Ha habido un reciente bloqueo parcial de PoS en Ethereum. Debido a algunos errores en el cliente de Prysm, el dispositivo de finalidad no funcionaba. Así que Prysm tuvo que salir y corregir su error y volver a implementar. Entonces, incluso en estas redes en capas en tiempo real, a veces nos encontramos con lugares donde se requiere la intervención humana para proteger el sistema. Creo que esto también es necesario para el resumen. Pero necesitamos tener algunos procedimientos efectivos para saber quién tiene la autoridad y responsabilizarlos por el sistema de acumulación.