¿Ethereum "cambiar a RISC-V" asustará a los desarrolladores? OG advierte: la ecología de ETH se redistribuirá, los pequeños proyectos se irán a Solana.
El fundador de Ethereum, V God, propuso reemplazar "RISC-V" con Ethereum en la capa de ejecución para reemplazar el EVM anterior, lo que hizo que algunos desarrolladores sospecharan, y en 2016, el desarrollador de Ethereum, OG, creyó que esto haría que el ecosistema de Ethereum se enfrentara a la redistribución y sería muy hostil para los proyectos de pequeño capital. (Sinopsis: Las tarifas de manejo de Ethereum alcanzaron un mínimo de cinco años, y la comunidad desencadenó la "teoría del veneno L2": no hay autos en la carretera y V Dios todavía se ríe y construye autopistas) (Suplemento de antecedentes: Desmantelando la ambición estratégica de Vitalik de reconstruir la capa ejecutiva de Ethereum con "RISC-V en lugar de EVM") La reciente propuesta "RISC-V" del fundador de Ethereum, V God, ha atraído la atención de la comunidad de criptomonedas y ha causado debate entre los desarrolladores del ecosistema central, y para la mayoría de los usuarios, la mayoría de ellos no pueden entender RISC-V ¿Cómo reformar Ethereum y qué tipo de progreso puede traer la propuesta de V-God a Ethereum? Para responder a esta pregunta, entrevistamos a un viejo "dragón antiescala" de OG que ha estado desarrollando la ecología central de Ethereum desde 2016, y responderá al proceso detallado de revisión de "RISC-V" y los efectos negativos a corto plazo que pueden ocurrir en el futuro, recordando a todos los inversores de Ethereum que presten mucha atención al seguimiento de esta propuesta. Cómo renovar la situación de RISC-V Ethereum se diferencia de otras cadenas PoS en que el cliente de Ethereum se compone de dos partes, la "capa de consenso" y la "capa de ejecución", y la capa de consenso es responsable de empaquetar la votación de las participaciones, y la capa de ejecución es responsable de procesar las transacciones, por lo que el código que ejecuta el contrato inteligente es en realidad un cliente de capa de ejecución ejecutado por la computadora del nodo, que ejecuta el código tomando la transmisión de la transacción y escribe los resultados de la votación a través de la "capa de consenso" en el libro mayor público. La única forma de actualizar el entorno EVM actual a RISC-V es actualizando el "cliente de la capa de ejecución" del cliente del nodo, que es solo una bifurcación a nivel de software, a diferencia de la bifurcación dura habitual en el pasado para cambiar el bloque Ethereum y la revisión del nodo correspondiente. De acuerdo con la descripción del contenido del artículo de V God, idealmente, si todos los clientes de nodo tienen ejecutores RISC-V, entonces el funcionamiento del protocolo para la nueva versión y el funcionamiento de la prueba zk pueden lograr casi 100 veces la eficiencia teórica, pero debe saberse que esto se calcula en el contrato inteligente para la versión RISC-V y el cliente RISC-V, en relación con el formato de contrato inteligente EVM ejecutado en el cliente EVM. Lo especial de la propuesta de RISC-V esta vez es que se ha renovado directamente en el cliente de capa ejecutiva y no usará la parte de la bifurcación dura, lo que no me gusta mucho, pero se puede ver que Ethereum se está moviendo en una nueva dirección, lo que puede ser un filo de doble filo, y este nivel de cambio en el pasado Ethereum puede optar por implementarse con una bifurcación dura, porque puede ser un enfoque más seguro. Correspondencia entre la situación actual y el contrato anterior Después de comprender el rendimiento de la teoría, veamos cuál es la situación actual, la situación actual es que toda la ecología de Ethereum y todas las prácticas de EIP se ejecutan con éxito a través de contratos inteligentes EVM y clientes EVM, si como V Dios dijo que RISC-V tendrá un transpilador EVM, entonces la situación futura real se puede dividir en las siguientes situaciones Los contratos inteligentes EVM se ejecutan en el cliente EVM (el antiguo EIP es totalmente compatible, pero el nuevo EIP debe corresponder a dos versiones) El contrato inteligente EVM se ejecuta en el cliente RISC-V a través del transpilador EVM de RISC-V (los EIP antiguos y nuevos deben pasar por muchas pruebas y depuraciones para resolverlos) El contrato inteligente RISC-V se ejecuta en el cliente RISC-V (se volverán a probar todos los EIP antiguos, pero el nuevo EIP debería ser perfectamente compatible) En resumen, teniendo en cuenta el rendimiento teórico de la futura eficiencia operativa del contrato inteligente de 100 veces, solo se aplica el tercer estado, y para el segundo caso, En particular, se basa en la optimización del transpilador por parte del equipo central de Ethereum, así como en todas las actualizaciones de EIP y contratos inteligentes en el pasado, lo que significa que Ethereum debe pagar un precio de optimización muy alto para lograr una mejora teórica del rendimiento, y no está claro si la optimización de la eficiencia del antiguo código EVM a través de la traducción en RISC-V es definitivamente mayor que la del entorno EVM nativo. De hecho, V Dios dijo esto, supongo que debe haber muchos desarrolladores principales que se sienten muy desesperados, en el pasado en el desarrollo de EVM, para resolver cada implementación y prueba de EIP, la carga de trabajo ya es muy grande, porque Ethereum es una comunidad a la que le gusta probar respuestas abiertas en un entorno muy abierto. Pero ahora, cuando se convierte en un entorno RISC-V, solo pienso en el período de prueba de transformación, que es un gran dolor de cabeza, el problema principal es que es posible que no pueda ejecutar más de 1 ~ 5 veces más eficiente que el entorno original durante el período de prueba, por lo que supongo que este período de prueba continuará extendiéndose muchas veces, al igual que Ethereum Merge en el pasado, por lo que hay una falta de resultados concretos en la etapa inicial, y es difícil atraer ecosistemas externos para implementar en la red de prueba y enviar comentarios. Solo puedo decir que V God tiene grandes ambiciones, pero no creo que la implementación sea muy optimista, al menos creo que más de la mitad de los desarrolladores principales pueden no estar muy contentos, si están decididos a cambiar a RISC-V, V God y la Fundación Ethereum deben dedicar mucho esfuerzo para fomentar el equipo de desarrolladores principales y la ecología. El problema de la correspondencia ecológica con RISC-V El dragón mencionó que el mayor problema de la propuesta de RISC-V puede provenir del apoyo y la correspondencia del proyecto privado de ecología, en el ecosistema de código abierto existente, los componentes que se pueden utilizar son muy limitados, por lo que el eslogan de la traducción de EVM a RISC-V propuesto por V Dios puede tener muchas dudas y problemas a corto plazo. Por ejemplo, el ecosistema existente de Ethereum, como los proyectos y contratos de EVM que no tienen problemas, bajo la premisa de la traducción de EVM a RISC-V, puede haber una falta de estado o terminación de operaciones en el proceso de ejecución del contrato en la capa de ejecución, lo que significa que incluso proyectos antiguos de EVM que no han tenido ningún problema en el pasado, en el caso de usar la traducción de EVM a RISC-V, puede haber tokens que no se puedan proponer, o se quemen o bloqueen accidentalmente. Es muy probable que un ejemplo de este tipo haga que el equipo del proyecto ecológico, en algunos casos, no esté dispuesto a abrir a los usuarios a utilizar el transpilador EVM a RISC-V para ejecutar contratos inteligentes EVM heredados; Además, para evitar riesgos relacionados y hacer un seguimiento de la nueva tecnología de Ethereum, la mejor manera para el ecosistema del proyecto es escribir una nueva versión RISC-V del contrato para todos los contratos inteligentes, y la conexión entre el contrato antiguo y el nuevo contrato se resuelve a través del puente de activos. De hecho, la forma de participar en la compatibilidad es muy fácil de empaquetar, pero si la fundación está dispuesta a dispersar dinero para obtener la solución general, entonces puede resolver el 99% de los problemas de compatibilidad, pero el problema radica en el 1% restante y la confianza en la seguridad de los desarrolladores ecológicos. Ahora pregúntele a los desarrolladores de proyectos de Ethereum, supongo que no tendré tanta confianza en la parte de la traducción de EVM RISC-V, las grandes empresas de tecnología de capital quieren pertenecer a sus propios sistemas o chips personalizados de principio a fin, no necesariamente elegirán RISC-V, porque aunque esta arquitectura es de código abierto, en comparación con las arquitecturas convencionales como ARM y X86, el soporte ecológico de RISC-V es muy limitado y no hay un desarrollo relacionado de la cadena de bloques, lo que significa que Ethereum tiene que abrir un mundo con las manos desnudas. Si en el examen...
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.
¿Ethereum "cambiar a RISC-V" asustará a los desarrolladores? OG advierte: la ecología de ETH se redistribuirá, los pequeños proyectos se irán a Solana.
El fundador de Ethereum, V God, propuso reemplazar "RISC-V" con Ethereum en la capa de ejecución para reemplazar el EVM anterior, lo que hizo que algunos desarrolladores sospecharan, y en 2016, el desarrollador de Ethereum, OG, creyó que esto haría que el ecosistema de Ethereum se enfrentara a la redistribución y sería muy hostil para los proyectos de pequeño capital. (Sinopsis: Las tarifas de manejo de Ethereum alcanzaron un mínimo de cinco años, y la comunidad desencadenó la "teoría del veneno L2": no hay autos en la carretera y V Dios todavía se ríe y construye autopistas) (Suplemento de antecedentes: Desmantelando la ambición estratégica de Vitalik de reconstruir la capa ejecutiva de Ethereum con "RISC-V en lugar de EVM") La reciente propuesta "RISC-V" del fundador de Ethereum, V God, ha atraído la atención de la comunidad de criptomonedas y ha causado debate entre los desarrolladores del ecosistema central, y para la mayoría de los usuarios, la mayoría de ellos no pueden entender RISC-V ¿Cómo reformar Ethereum y qué tipo de progreso puede traer la propuesta de V-God a Ethereum? Para responder a esta pregunta, entrevistamos a un viejo "dragón antiescala" de OG que ha estado desarrollando la ecología central de Ethereum desde 2016, y responderá al proceso detallado de revisión de "RISC-V" y los efectos negativos a corto plazo que pueden ocurrir en el futuro, recordando a todos los inversores de Ethereum que presten mucha atención al seguimiento de esta propuesta. Cómo renovar la situación de RISC-V Ethereum se diferencia de otras cadenas PoS en que el cliente de Ethereum se compone de dos partes, la "capa de consenso" y la "capa de ejecución", y la capa de consenso es responsable de empaquetar la votación de las participaciones, y la capa de ejecución es responsable de procesar las transacciones, por lo que el código que ejecuta el contrato inteligente es en realidad un cliente de capa de ejecución ejecutado por la computadora del nodo, que ejecuta el código tomando la transmisión de la transacción y escribe los resultados de la votación a través de la "capa de consenso" en el libro mayor público. La única forma de actualizar el entorno EVM actual a RISC-V es actualizando el "cliente de la capa de ejecución" del cliente del nodo, que es solo una bifurcación a nivel de software, a diferencia de la bifurcación dura habitual en el pasado para cambiar el bloque Ethereum y la revisión del nodo correspondiente. De acuerdo con la descripción del contenido del artículo de V God, idealmente, si todos los clientes de nodo tienen ejecutores RISC-V, entonces el funcionamiento del protocolo para la nueva versión y el funcionamiento de la prueba zk pueden lograr casi 100 veces la eficiencia teórica, pero debe saberse que esto se calcula en el contrato inteligente para la versión RISC-V y el cliente RISC-V, en relación con el formato de contrato inteligente EVM ejecutado en el cliente EVM. Lo especial de la propuesta de RISC-V esta vez es que se ha renovado directamente en el cliente de capa ejecutiva y no usará la parte de la bifurcación dura, lo que no me gusta mucho, pero se puede ver que Ethereum se está moviendo en una nueva dirección, lo que puede ser un filo de doble filo, y este nivel de cambio en el pasado Ethereum puede optar por implementarse con una bifurcación dura, porque puede ser un enfoque más seguro. Correspondencia entre la situación actual y el contrato anterior Después de comprender el rendimiento de la teoría, veamos cuál es la situación actual, la situación actual es que toda la ecología de Ethereum y todas las prácticas de EIP se ejecutan con éxito a través de contratos inteligentes EVM y clientes EVM, si como V Dios dijo que RISC-V tendrá un transpilador EVM, entonces la situación futura real se puede dividir en las siguientes situaciones Los contratos inteligentes EVM se ejecutan en el cliente EVM (el antiguo EIP es totalmente compatible, pero el nuevo EIP debe corresponder a dos versiones) El contrato inteligente EVM se ejecuta en el cliente RISC-V a través del transpilador EVM de RISC-V (los EIP antiguos y nuevos deben pasar por muchas pruebas y depuraciones para resolverlos) El contrato inteligente RISC-V se ejecuta en el cliente RISC-V (se volverán a probar todos los EIP antiguos, pero el nuevo EIP debería ser perfectamente compatible) En resumen, teniendo en cuenta el rendimiento teórico de la futura eficiencia operativa del contrato inteligente de 100 veces, solo se aplica el tercer estado, y para el segundo caso, En particular, se basa en la optimización del transpilador por parte del equipo central de Ethereum, así como en todas las actualizaciones de EIP y contratos inteligentes en el pasado, lo que significa que Ethereum debe pagar un precio de optimización muy alto para lograr una mejora teórica del rendimiento, y no está claro si la optimización de la eficiencia del antiguo código EVM a través de la traducción en RISC-V es definitivamente mayor que la del entorno EVM nativo. De hecho, V Dios dijo esto, supongo que debe haber muchos desarrolladores principales que se sienten muy desesperados, en el pasado en el desarrollo de EVM, para resolver cada implementación y prueba de EIP, la carga de trabajo ya es muy grande, porque Ethereum es una comunidad a la que le gusta probar respuestas abiertas en un entorno muy abierto. Pero ahora, cuando se convierte en un entorno RISC-V, solo pienso en el período de prueba de transformación, que es un gran dolor de cabeza, el problema principal es que es posible que no pueda ejecutar más de 1 ~ 5 veces más eficiente que el entorno original durante el período de prueba, por lo que supongo que este período de prueba continuará extendiéndose muchas veces, al igual que Ethereum Merge en el pasado, por lo que hay una falta de resultados concretos en la etapa inicial, y es difícil atraer ecosistemas externos para implementar en la red de prueba y enviar comentarios. Solo puedo decir que V God tiene grandes ambiciones, pero no creo que la implementación sea muy optimista, al menos creo que más de la mitad de los desarrolladores principales pueden no estar muy contentos, si están decididos a cambiar a RISC-V, V God y la Fundación Ethereum deben dedicar mucho esfuerzo para fomentar el equipo de desarrolladores principales y la ecología. El problema de la correspondencia ecológica con RISC-V El dragón mencionó que el mayor problema de la propuesta de RISC-V puede provenir del apoyo y la correspondencia del proyecto privado de ecología, en el ecosistema de código abierto existente, los componentes que se pueden utilizar son muy limitados, por lo que el eslogan de la traducción de EVM a RISC-V propuesto por V Dios puede tener muchas dudas y problemas a corto plazo. Por ejemplo, el ecosistema existente de Ethereum, como los proyectos y contratos de EVM que no tienen problemas, bajo la premisa de la traducción de EVM a RISC-V, puede haber una falta de estado o terminación de operaciones en el proceso de ejecución del contrato en la capa de ejecución, lo que significa que incluso proyectos antiguos de EVM que no han tenido ningún problema en el pasado, en el caso de usar la traducción de EVM a RISC-V, puede haber tokens que no se puedan proponer, o se quemen o bloqueen accidentalmente. Es muy probable que un ejemplo de este tipo haga que el equipo del proyecto ecológico, en algunos casos, no esté dispuesto a abrir a los usuarios a utilizar el transpilador EVM a RISC-V para ejecutar contratos inteligentes EVM heredados; Además, para evitar riesgos relacionados y hacer un seguimiento de la nueva tecnología de Ethereum, la mejor manera para el ecosistema del proyecto es escribir una nueva versión RISC-V del contrato para todos los contratos inteligentes, y la conexión entre el contrato antiguo y el nuevo contrato se resuelve a través del puente de activos. De hecho, la forma de participar en la compatibilidad es muy fácil de empaquetar, pero si la fundación está dispuesta a dispersar dinero para obtener la solución general, entonces puede resolver el 99% de los problemas de compatibilidad, pero el problema radica en el 1% restante y la confianza en la seguridad de los desarrolladores ecológicos. Ahora pregúntele a los desarrolladores de proyectos de Ethereum, supongo que no tendré tanta confianza en la parte de la traducción de EVM RISC-V, las grandes empresas de tecnología de capital quieren pertenecer a sus propios sistemas o chips personalizados de principio a fin, no necesariamente elegirán RISC-V, porque aunque esta arquitectura es de código abierto, en comparación con las arquitecturas convencionales como ARM y X86, el soporte ecológico de RISC-V es muy limitado y no hay un desarrollo relacionado de la cadena de bloques, lo que significa que Ethereum tiene que abrir un mundo con las manos desnudas. Si en el examen...