Despejando el camino para la adopción de sharding Vitalik propone un nuevo enfoque compatible con versiones anteriores de Ethereum.

Uno de los desafíos con la compatibilidad con versiones anteriores en el diseño actual de Ethereum es que el acceso al historial de la cadena de bloques requiere la verificación de EVM de las pruebas de Merkle, que también supone que la cadena de bloques siempre usará el mismo formato y la misma criptografía. Los futuros diseños de fragmentación aumentarán la importancia de esto, ya que las pruebas de fraude y las pruebas de validez de Rollup requerirán punteros a los datos fragmentados.

Esta publicación propone un enfoque más preparado para el futuro: en lugar de requerir que las pruebas históricas y fragmentadas se verifiquen en el EVM, podemos agregar precompilaciones que realizan la tarea abstracta de verificar pruebas de un tipo específico. Si el formato cambia en el futuro, la lógica de precompilación cambiará automáticamente. Las precompilaciones pueden incluso tener una lógica condicional que verifique una prueba para un espacio previo a la transición y otra prueba para un espacio posterior a la transición.

def verificarHistoricalBlockRoot( ranura: uint256, valor: bytes32, prueba: bytes ) Esta precompilación intentará interpretar la prueba de una de dos maneras:

Si la prueba está vacía, verifique directamente si el valor es la raíz del bloque histórico almacenada en la ubicación correcta. Fallará si la ranura es demasiado antigua.

Si la prueba es una rama de Merkle, la verifica como una rama de Merkle según la entrada correcta en history_roots

def verificarHistoricalStateRoot( ranura: uint256, valor: bytes32, prueba: bytes ) Verifique la raíz del estado, usando la misma lógica que esta raíz de bloque.

Gate.io lanzó el comercio de contratos perpetuos de SUSHI (liquidación de USDT): según el anuncio del sitio web oficial, Gate.io ha lanzado el comercio real de contratos perpetuos de SUSHI (liquidación de USDT), que admite operaciones largas y cortas de 1 a 20 veces, y el índice de apalancamiento puede Sea Elija usted mismo cuando realice un pedido. El contrato perpetuo de Gate.io es uno de los mercados de contratos de activos de blockchain más activos del mundo, con un volumen de operaciones diario de hasta 800 millones de dólares EE. UU. Los tipos de liquidación se dividen en "contrato perpetuo liquidado en BTC" y "contrato perpetuo liquidado en USDT". ". [2020/9/1]

def verificarHistoricalStateValue(ranura: uint256, clave: bytes32, valor: bytes32, prueba: bytes) Verifica el valor en el estado histórico. Esta prueba incluye tres elementos:

Una prueba que muestra la exactitud de la raíz del estado

Prueba de Patricia o Verkle u otra prueba de que el valor está realmente en la clave de posición en el árbol de estado (esto supone que el esquema propuesto de asignar todo el contenido de la cuenta a una clave de 32 bytes se ha conservado para siempre)

def verificarTransacción Histórica (ranura: uint256, txindex: uint256, tx: bytes, prueba: bytes) Verifique que tx esté realmente en el txindex del bloque de la ranura dada. El contenido de la prueba es el siguiente:

Una prueba de la corrección de la raíz del bloque

Demostrar que un tx dado es en realidad una transacción en una ubicación dada

defcheckHistoricalReceipt(ranura: uint256, txindex: uint256, recibo: bytes, prueba: bytes) Verifique que el recibo sea realmente un recibo de transacción en txindex para la ranura dada. El contenido de la prueba es el siguiente:

Prueba de la corrección de la raíz del bloque

Prueba de que un recibo dado es en realidad un recibo para una ubicación determinada

def verificarShardBlockBody( ranura: uint256, fragmento: uint256, startChunk: uint256, fragmentos: uint256, datos: bytes, prueba: bytes ) verificar datos = cuerpo[32 * startChunk: 32 * (startChunk) + fragmento, donde se proporciona el cuerpo del fragmento dado en la ranura. Esta prueba incluirá:

Kate prueba demostrando un subconjunto de bloques

Si la ranura es demasiado antigua (¿más de 128 épocas?), una prueba de Merkle de la raíz del bloque en la ranura + 96, seguida de una prueba de Merkle desde esa ranura hasta la posición en la matriz de compromiso de fragmentos, que muestra un compromiso de finalidad

Cuando usamos el compromiso Kate BLS-12-381, la precompilación también verificará que los datos sean una lista de fragmentos de 32 bytes, donde cada fragmento es más pequeño que el orden del subgrupo de la curva. Si no se guarda ningún fragmento de fragmento en una ubicación determinada, la precompilación actúa como si se guardara una promesa de datos de longitud cero en esa ubicación. La precompilación siempre falla si el valor en la posición dada no está confirmado.

def verificarEvaluación polinomial de fragmento (ranura: uint256, fragmento: uint256, x: uint256, y: uint256, prueba: bytes) Si consideramos el bloque de fragmento en el (ranura, fragmento) dado como polinomio P, donde el byte i*32. .. i *32+31 es la evaluación en w**i, que verifica que P(x) = y. La prueba es la misma que la prueba del subconjunto de datos, excepto que la prueba de Kate prueba la evaluación de un punto (posiblemente fuera del dominio) en lugar de probar un subconjunto de ubicación de los datos.

Si ya no usamos BLS-12-381 en el futuro (por ejemplo, usamos pruebas de campo binario de 32 bytes), la precompilación tomará SNARK como entrada, verificará que los datos consisten completamente en valores menores que el orden de la curva, y verifique que el campo actual Evaluación de datos.

Esta precompilación es útil para pruebas de protocolos de equivalencia entre esquemas de compromiso polinomial y se puede usar para permitir que ZK Rollup opere directamente en datos fragmentados.

Autor: Vitalik Buterin

Original: https://ethresear.ch/t/future-proof-shard-and-history-access-precompiles/9781

Tags：

OKX Official