Entienda Truebit en cinco minutos: mecanismo de protocolo, escenarios de aplicación y modelo económico

Como un proyecto veterano de Capa 2 lanzado durante la última ronda del mercado alcista, Truebit finalmente se puso en marcha de manera discreta a fines de abril. A medida que el precio de sus tokens continúa aumentando y las discusiones en torno a su mecanismo de fijación de precios especial y las oportunidades de arbitraje de TruebitOS, el entusiasmo de la comunidad de Truebit continúa aumentando. Este artículo intenta ayudar a los usuarios a obtener una visión general del proyecto al clasificar el mecanismo del protocolo, los escenarios de aplicación y los modelos económicos de la red Truebit. Además, también echaremos un vistazo más de cerca a la última solución Optimistic Rollup EVM de V God con lectores. Finalmente, si desea practicar la participación en la red Truebit, no se pierda la detallada guía al final del artículo. Actualmente, Ethereum tiene los siguientes problemas: el rendimiento general es bajo. Consume mucha potencia informática, pero el rendimiento solo es equivalente a un teléfono inteligente. La validación es baja. Este problema se conoce como el dilema del verificador. Los nodos que han obtenido los derechos de empaquetado son recompensados ​​y otros nodos necesitan verificar, pero no reciben recompensas y el entusiasmo por la verificación es bajo. Con el tiempo, es posible que los cálculos no se verifiquen, lo que plantea riesgos para la seguridad de los datos en la cadena. La cantidad de cálculo es limitada (gasLimit) y el costo de cálculo es alto. El problema anterior es causado por el diseño de que todos los nodos (completos) de Ethereum realizan la verificación. La cantidad de cómputo redundante es demasiado alta. TrueBit reduce el diseño de "verificación de redundancia de nodo completo" de las tareas informáticas a una verificación redundante en solo unos pocos nodos fuera de la cadena. El protocolo TrueBit incluye un contrato inteligente. Los usuarios pueden enviar una tarea informática al contrato inteligente y pagar un precio por esta tarea. Estos usuarios se denominan Task Givers; Solver es un participante que desea completar la tarea y obtener recompensas; Solver handover Put algún margen al contrato, para que pueda ser asignado a la tarea y ser recompensado al completar esta tarea de cálculo. Entonces, ¿cómo juzgar si el resultado dado por Solver es correcto? Hay un papel de Challenger para confirmar si el resultado dado por el Solver es correcto. Si se encuentra que es incorrecto, iniciará un desafío para ganar recompensas. Cuando el contrato encuentre que ocurre un desafío, organizará un juego de verificación para confirmar quién tiene la razón entre el solucionador y el Desafiador. Como se puede ver en la introducción del marco del protocolo en la sección anterior, cuando hay un desacuerdo, se requiere un juego de verificación para juzgar quién tiene la razón entre el solucionador y el retador. Este juego de verificación está organizado por contratos inteligentes. Si el contrato inteligente necesita pagar muchos cálculos por esto, el costo de funcionamiento en la cadena será muy alto y puede exceder el gasLimit. Nuestro objetivo es tener la menor computación posible en la cadena. La forma actual de lograr este objetivo es dejar que Solver y Challenger descubran el primer punto de bifurcación en el proceso de cálculo de ambas partes. La cantidad de cálculo desde el último punto hasta el primer punto de bifurcación es muy pequeña, siempre que este punto se ejecuta en el contrato Calcular y se puede juzgar quién está en lo correcto. El protocolo específico se describe brevemente de la siguiente manera: en la etapa de bucle principal, se supone que hay dudas sobre el cálculo en el intervalo de tiempo t, y el tiempo t se divide en c partes iguales, de modo que el solucionador pueda representar el estado de cada punto de tiempo con un árbol merkle. Los nodos hoja del árbol son todas variables de estado de la máquina. , Envíe c merkle hashes raíz al contrato. Si el retador encuentra el hash en el i-ésimo punto de tiempo, es el primer punto de tiempo que no coincide con el hash calculado localmente. Someter i al contrato. El juez verifica la legitimidad de los hashes C y el número i. El siguiente paso es tomar el intervalo de tiempo entre i-1 e i como objeto de sospecha, y repetir los pasos anteriores recursivamente. Después de un cierto número de recursiones (log t /log c), el solucionador Envía primero todos los estados de la máquina que no coinciden con los puntos de tiempo e y e-1, y el juez verifica quién está en lo correcto entre Solver y Challenger. El mecanismo de jackpot (jackpot) Solver da sus propios resultados de cálculo, y Verifiers hace cálculos repetidos y verifica si los resultados proporcionados por Solver son correctos. Esta es la lógica de funcionamiento normal. Pero esta lógica adolece de los siguientes problemas. Si a los Verificadores se les asignan tareas de verificación y se les paga por esto, entonces es posible que los Verificadores no hagan cálculos dobles en absoluto (no paguen ningún costo computacional por esto) y secunden directamente los resultados del Solver, lo cual es muy peligroso para el protocolo. Si solo pagamos a los verificadores por los errores que encuentran, entonces no están seguros de cuándo encontrarán un error y, de hecho, es posible que no encuentren un error durante mucho tiempo.Desde el punto de vista esperado y práctico, el verificador tiene ningún incentivo para participar. Si a veces **"exponemos intencionalmente un error"**, y damos una gran recompensa al verificador que encuentra este error, entonces el verificador seguirá verificando, tratando de encontrar este error. Este "error expuesto intencionalmente" se llama "error forzado". El mecanismo completo se llama mecanismo de premio mayor, que fue diseñado por Vitalik, el fundador de Ethereum, y se agregó al protocolo TrueBit en 2017. Escenarios de implementación y aplicación Para implementar el juego de verificación, es necesario unificar la arquitectura de instrucción.El proyecto TrueBit originalmente quería usar la arquitectura Lanai para implementarlo, pero luego descubrió que la implementación del compilador Lanai era lenta. Actualmente usa WebAssembly en su lugar. Estos son los escenarios de aplicación de la planificación inicial de TrueBit (no había un concepto de expansión de RollUp en ese momento. Ayer, después del lanzamiento de TrueBit OS, Vitalik le dio a TrueBit una propuesta para un RollUp optimista, consulte la siguiente sección para obtener más detalles): Poder de cómputo subcontratado : Antes Hay muchos pools de minería descentralizados que se han introducido: la ventaja de los pools de minería descentralizados es evitar que un solo punto (el operador del pool de minería centralizado) sea atacado. Los grupos de minería descentralizados se pueden implementar a través de contratos inteligentes, pero el trabajo como verificar que el POW de ZCash excede el gasLimit se puede superar a través del mecanismo TrueBit. Ayude a realizar tales grupos de minería descentralizados. Mejorar el rendimiento de las "transacciones" Los mineros deben hacer lo siguiente: tarea 1: Seleccionar transacciones y empaquetarlas en bloques. tarea 2: Verificar la legitimidad de las transacciones en el bloque. Se puede usar un protocolo para poner task2 fuera de la cadena para que Solver y Verifiers lo ejecuten. Esto ahorra muchos cálculos dobles. Las "Transacciones" complejas se pueden colocar de forma segura en la cadena. Revisión del protocolo El juego de verificación interactivo del protocolo TrueBit permite a los usuarios enviar (externalizar) cualquier tarea informática y obtener un resultado correcto. TrueBit reduce el trabajo de verificación redundante de otros mineros y optimiza la estructura de recompensas. Problema del dilema del verificador mitigado. V God propuso ayer un plan para construir un Optimistic Rollup EVM basado en Truebit. El enlace al artículo original considera a Truebit como una caja negra, es decir, puede ingresarle instrucciones y esperar que devuelva el resultado después de un período de retraso. En base a esto, el modelo puede generar un resumen optimista de EVM. Truebit puede aceptar instrucciones de WebAssembly (WASM), y la mayoría de los lenguajes de alto nivel actuales se pueden compilar en códigos de bytes WASM, como C++, Go, Rust, Java, etc., lo que significa que los clientes de Ethereum escritos en estos lenguajes pueden también se compilará en WASM se implementa en Truebit. Si desea construir EVM basado en Truebit, el primer paso es construir un cliente Ethereum sin estado. El cliente sin estado se puede implementar de esta manera. Los datos de estado requeridos para ejecutar el bloque se pasan al cliente como un parámetro de entrada en forma de una tabla de consulta de estado. Tal cliente no necesita mantener el estado en sí mismo y puede abstraerse en un funcional puro El método process_block(state_lookup_table, block) -> post_state_root, un cliente sin estado puramente funcional puede compilarse en wasm y entregarse a Truebit para su ejecución. El segundo paso es construir los módulos en la cadena, una dificultad aquí es que la cadena de bloques tiene estado. Si el bloque N de la cadena acumulada optimista comienza a ejecutar el proceso a prueba de fraude, hay una premisa implícita de que los datos de estado relacionados con stateRoot en el bloque N están disponibles. Debido a esta premisa, cuando se envía un bloque erróneo, las personas pueden probar el error del bloque en primer lugar. Sin embargo, Truebit es un sistema informático interactivo sin estado puramente funcional. Podemos eludir tales limitaciones a través de unos pocos pasos del proceso de verificación interactivo fuera de la llamada de Truebit. El proceso de la solución se puede diseñar de la siguiente manera: el bloque hash y stateRoot se almacenan en el contrato de la cadena: List[Tuple[block_hash, state_root]] secuenciador (determinado por el implementador, uno o más) es responsable de agregar bloques , Al llamar al método add_block(expected_pre_state: bytes32, block: bytes, post_state: bytes32), este método necesita pasar stateRoot antes de la ejecución como parámetro y luego agregar ((block, post_state)) a la cadena. El retador (Challenger) puede desafiar un stateRoot llamando al método challenge(index: int, lookup_table: bytes, block: bytes) que ejecutará la siguiente lógica: verificar que el bloque enviado sea consistente con el valor hash guardado Hacer una llamada Truebit process_block() para ejecutar el cálculo del contenido del bloque y guardar la raíz de Merkle de la tabla de consulta. Una vez que comienza un desafío, cualquiera puede desafiar la tabla de consulta proporcionada por el retador. Puede ser incorrecto al enviar un preStateRoot como el valor raíz A en el Camino de Merkel se compara con el mismo valor en el Camino de Merkel proporcionado por el retador.Si hay un conflicto, significa que hay un problema con el retador, y el retador será castigado. Una vez que Truebit devuelve el resultado post_state_root del bloque de ejecución después de un período de espera, significa que el desafío es normal (es decir, nadie prueba que haya un problema con el retador), es decir, el resultado devuelto es el resultado correcto de la ejecución normal del bloque. Luego, en base a la suposición de que el resultado es correcto, se ejecutará la siguiente lógica: Si el resultado es inconsistente con post_state_root enviado anteriormente y no es un error ERROR: LOOKUP_TABLE_MISSING_NEEDED_VALUE, entonces el desafío es exitoso y la persona que enviado originalmente será castigado por otros Continúe enviando bloques correctos y datos de estado para reemplazar bloques y estados incorrectos. Si el resultado coincide con el post_state_root enviado anteriormente o se encuentra con un error ERROR: LOOKUP_TABLE_MISSING_NEEDED_VALUE , entonces se penalizará al retador. El token de Truebit es TRU, que utilizan los remitentes de tareas para pagar a los solucionadores y verificadores. Después de recibir el pago, los solucionadores (Solvers) y los verificadores (Verifiers) pueden comenzar la ejecución de la tarea. A continuación, profundizamos en los detalles macroeconómicos. Método de suministro de tokens TRU Los tokens TRU se crearán y destruirán con el tiempo en función de la demanda acumulada. Los usuarios pueden _comprar_ o _salir_ tokens TRU con ETH. Cada transacción de compra deposita una parte de ETH en el depósito en garantía de la reserva (el resto pertenece a la empresa), y cada transacción de venta retira una parte de ETH de la reserva. Cada tarea de Truebit también quema tokens TRU. A través del comando _mission fee en Truebit OS, puede conocer el _burn rate_ y el _token price actuales, lo que ayuda a comprender el precio actual de compra y salida de TRU. Vale la pena señalar que comprar puede hacer que el precio baje, pero salir no. Incentivos de tiempo limitado La capa de incentivos de Truebit actualmente proporciona incentivos TRU adicionales para cada tarea dentro de un tiempo limitado, y la TRU se otorga al propietario, solucionador y verificador correspondiente de la tarea. Ejecute el comando Bonificación en Truebit OS para verificar el monto de la bonificación actual. Tarifas de ETH Además de los gastos generales de TRU anteriores para el "proveedor de tareas", los usuarios también generarán algunas tarifas de Ethereum (ETH), que se utilizan principalmente para pagar el gas generado al interactuar con Ethereum. Por cada tarea, Truebit (la empresa) también cobrará una pequeña cantidad de ETH al solucionador y al remitente de la tarea como tarifa de uso de la plataforma (el verificador no paga la tarifa de la plataforma). Cada solucionador también debe comprar una tarifa de licencia única (pagada a Truebit) para unirse a la red de tareas. En Truebit OS, puede conocer los precios relevantes a través del comando de costo de la tarea.

Tags：

Precio de Etéreo