Hasta ahora, el mito del bienestar en la industria del círculo monetario/blockchain continúa, y la siguiente área importante de "creación de riqueza" se centra en la "pista del juego". El proyecto XAI está organizando un evento Odyssey. Si está interesado, participe en este artículo mío en la plaza: Guía para principiantes de costo cero del evento Odyssey de la cadena pública de juegos XAI.
¡En este artículo, les brindaré una explicación detallada del nodo Sentry de la cadena pública del juego XAI! Este artículo es relativamente técnico, por lo que si estás interesado en ganar dinero, debes leerlo detenidamente. Porque sólo si usted mismo comprende la "lógica" y mejora su cognición, ¡podrá tener la oportunidad de ganar dinero!
Si desea ver directamente sobre el nodo Sentry, lea la primera parte directamente sin leer más tarde, si desea un bucle cerrado lógico, ¡entonces debe leer la segunda, tercera y cuarta parte!
Lo que quiero enfatizar es que Xai recibe soporte técnico directo de Offchain Labs. ¡Este tipo de soporte es inimaginable para otras cadenas Orbit! y es un componente clave del plan estratégico de Xai dentro del ecosistema Arbitrum.
Parte 1: explicación del nodo centinela
El nodo Sentry es un nodo de observación que monitorea el protocolo acumulativo de Xai y, si se propone un bloqueo incorrecto, emitirá una alerta (por cualquier medio que elija su operador) para que otros puedan intervenir. El propósito del ganglio centinela es resolver el dilema del verificador (consulte la Parte IV para obtener detalles sobre el dilema del verificador).
Haga clic aquí para ver el vídeo promocional:
Video de promoción del ganglio centinela
¡Ejecute nodos Xai y obtenga tokens Xai con un clic!
Los nodos Sentinel pueden ejecutarse en las computadoras portátiles, de escritorio o incluso en instancias de la nube de los miembros de la comunidad. Mientras el nodo esté en ejecución, existe un algoritmo probabilístico que determina si el operador del nodo será recompensado con tokens esXai de la red. Al apostar Xai, aumentas la probabilidad del algoritmo. Si no conoces esXai, por favor participa en mi artículo en la plaza: Interpretación de la “Economía Token” del proyecto XAI
1. Principio de funcionamiento del ganglio centinela
El protocolo Attention Challenge v2 involucra a múltiples participantes, incluida la cadena Xai, una cadena principal (Arbitrum One), un retador confiable, centinelas Xai y sus claves de licencia, y un contrato de Árbitro (árbitro). El retador crea un par de claves BLS, registra la clave pública del contrato de árbitro y firma las afirmaciones realizadas por el validador en el protocolo acumulativo de Xai en Arbitrum One. Estas firmas son verificadas por el contrato de árbitro y registradas como impugnaciones asociadas con el reclamo.
Xai Sentinels puede registrarse con el contrato de árbitro comprando una clave de licencia de Sentinel para ser elegible para publicar declaraciones sobre reclamos. Obtienen la raíz del estado de la declaración correcta que será la sucesora de la declaración emisora. Si se cumple una determinada condición, emiten una declaración sobre la declaración invocando el contrato de árbitro. Si se crea y confirma una declaración de seguimiento y Sentinel emite la declaración correcta, Sentinel se comunicará con el contrato de referencia para emitir una transacción de canje. El árbitro verificará varias condiciones antes de pagar la recompensa al Sentinel.
Este protocolo garantiza que cada reclamo debe consumir por completo los mensajes de la bandeja de entrada que existían cuando se creó el reclamo predecesor. Esto significa que una vez que se crea un reclamo, las raíces de estado de sus reclamos posteriores correctos están completamente determinadas y pueden ser calculadas por cualquier nodo. Esto anima a cada centinela a determinar la raíz del siguiente estado correcto. La recompensa del centinela está determinada por el ID de permiso del estado del centinela, la raíz del estado posterior y un valor de desafío que no se conoce hasta que se determina por completo la raíz del estado posterior.
2. ¿Quién puede ejecutar el nodo?
Cualquiera puede utilizar Sentinel descargando el software, instalándolo y ejecutándolo. Sin embargo, para recibir recompensas simbólicas, se debe comprar al menos una clave de licencia de Sentinel.
Los compradores deben pasar con éxito una verificación KYC para garantizar que:
no en los estados unidos
No sujeto a ninguna sanción de la OFAC de EE. UU. (la OFAC se refleja en una lista de sanciones de EE. UU.)
Aquellos nodos Sentinel que no estén en funcionamiento o no tengan los fondos adecuados para pagar las tarifas del gas (GAS) no acumularán recompensas, incluso con una clave de licencia. Por lo tanto, los operadores querrán asegurarse de que sus nodos estén financiados, en línea y en funcionamiento.
3. Contrato de árbitro (árbitro)
Referee es un contrato inteligente diseñado para hacer cumplir reglas predefinidas, verificar el origen de las presentaciones y distribuir recompensas a los ganadores dentro del sistema. El contrato inteligente de árbitro es un componente clave en el ecosistema Xai, responsable de gestionar y validar las reclamaciones realizadas por los nodos centinela en la red. El contrato tiene varias funciones clave:
3.1 Presentación de declaración
El contrato de árbitro permite a los ganglios centinela presentar reclamaciones ante impugnaciones. Esta función solo puede ser invocada por el propietario de la clave de licencia de Sentinel o su dirección aprobada en este contrato. Esta función verifica si el desafío aún está abierto para su envío y si ya se ha enviado una NodeLicense para este desafío.
3.2 Recibir recompensas
El contrato contiene una función que permite a los usuarios reclamar recompensas por reclamaciones exitosas. Esta función verifica si el desafío se ha cerrado para su envío y verifica si el propietario de la clave de nodo ha completado KYC. Si se cumplen estas condiciones y el reclamo es elegible para pago, la recompensa se enviará al usuario.
3.3 Crear hash de reclamo y verificar pago.
El contrato tiene una función que crea un hash del ID de permiso centinela, el ID del desafío, el ChallengerSignedHash en el desafío y la raíz del estado posterior. Luego verifica si el hash está por debajo de un cierto umbral, que se calcula en función del número total de licencias Sentinel que se han acuñado. Si el hash está por debajo del umbral, el reclamo es elegible para pago.
El contrato de árbitro garantiza la integridad de la red Xai al validar los reclamos y recompensar los exitosos, incentivando así a los nodos centinela a monitorear la red con precisión y diligencia.
4. Componente retador
El retador es una entidad confiable en el ecosistema Xai. Crea un par de claves BLS y registra la clave pública del contrato de árbitro. Cuando un validador hace un reclamo en el protocolo acumulativo de Xai, el retador firma el reclamo usando su clave privada y envía la firma al árbitro. El árbitro verifica la firma y la registra como impugnación asociada a la declaración. Este proceso garantiza la integridad de las reclamaciones realizadas en el protocolo acumulativo de Xai.
5. Clave (permiso de clave del nodo centinela, basado en NFT)
La clave de licencia Sentinel es un token único y no fungible (NFT) que se requiere para operar un nodo Sentinel en la red Xai. Las licencias Sentinel sirven como prueba de elegibilidad para que los nodos presenten reclamos y reciban recompensas. Se acuña enviando la cantidad correcta de ETH y el precio de acuñación se determina mediante un sistema de umbral creciente.
La licencia de nodo juega un papel clave en el contrato de árbitro. Cuando un nodo quiere enviar un reclamo a un desafío, debe proporcionar su ID de permiso Sentinel. El contrato de árbitro verifica si la licencia Sentinel es válida y si el nodo es el propietario de la licencia Sentinel o un operador aprobado (sección KYC anterior). Si se cumplen estas condiciones, el reclamo del nodo se somete al desafío.
Los permisos Sentinel también entran en juego al reclamar recompensas por reclamaciones exitosas. El contrato de árbitro verifica si el propietario de la licencia Sentinel ha completado KYC y si la declaración es elegible para el pago. Si se cumplen estas condiciones, la recompensa se envía al propietario de la licencia Sentinel.
En resumen, el permiso Sentinel es un componente clave en la red Xai, que regula el funcionamiento de los nodos Sentinel, la presentación de reclamos y la distribución de recompensas.
6. Descarga y ejecución del nodo
Para ejecutar un ganglio centinela, los usuarios sólo necesitan descargar un paquete de software específico. Este paquete se puede utilizar en una aplicación de escritorio o como herramienta de línea de comandos en su computadora. En pocas palabras, estas aplicaciones son herramientas que hacen que el software Sentinel sea más fácil de usar. El objetivo de este paquete es automatizar todas las operaciones necesarias para ejecutar Sentinel, haciéndolo muy sencillo de configurar y utilizar, incluso si no eres técnico.
Este paquete ayuda a los usuarios con tareas como configuración, administración e interacción con otras partes, y tiene una interfaz fácil de usar que permite a los usuarios ver y ajustar la configuración fácilmente. Con este paquete, los usuarios pueden centrarse más en cómo correr mejor y obtener más recompensas simbólicas. Los usuarios pueden optar por ejecutar este paquete utilizando una aplicación de escritorio o una herramienta de línea de comandos, las cuales son muy fáciles de usar y hacen que el proceso de operación sea muy sencillo.
7. Función de billetera centinela
En el ecosistema Xai, la billetera Sentinel juega un papel clave en la interacción entre los nodos Sentinel y los contratos inteligentes árbitros. Sentinel Wallet actúa como agente intermediario y es responsable de enviar declaraciones al árbitro en nombre de los Sentinels relevantes. Esto se logra a través de funciones específicas en el contrato de árbitro a las que solo puede acceder el propietario de la clave de licencia de Sentinel o su dirección aprobada en este contrato.
La billetera Sentinel puede enviar una declaración al desafío llamando a la función submitAssertionToChallenge en el contrato de árbitro. Esta función verifica si el desafío aún está abierto para su envío y si la clave de nodo ya se envió para este desafío.
Sentry Wallet también puede reclamar recompensas por reclamos exitosos llamando a la función ClaimReward en el contrato de árbitro. Esta función verifica si el desafío se ha cerrado para su envío y verifica si el propietario de la licencia Sentinel ha completado una verificación "KYC". Si se cumplen estas condiciones y el reclamo es elegible para pago, la recompensa se enviará al propietario del Sentinel.
En resumen, Sentinel Wallet actúa como un mensajero, facilitando la interacción entre nodos y árbitros, asegurando así el buen funcionamiento de la red Xai.
8. Licencia
La relación entre el número de licencias y las capacidades de envío del nodo es fundamental. Si bien es posible que un nodo tenga varias licencias asociadas, es importante tener en cuenta que la cantidad de licencias afecta directamente la capacidad del nodo para comprometerse. Básicamente, para garantizar cuotas de compromiso justas, la proporción de licencias e instancias de nodo se mantiene en 1:1. Siguiendo los principios anteriores, el sistema establece un enfoque estructurado para la concesión de licencias, la presentación de derechos y el funcionamiento general de los nodos dentro del ecosistema.
9.Requisitos de software y hardware del nodo centinela
El software del nodo Sentinel es compatible con el escritorio de Windows, Mac y Linux (requiere 64 bits). Los siguientes son los recursos actuales necesarios para ejecutar el software del nodo Sentinel para hasta 100 claves de licencia:
4 GB de RAM
2 núcleos de procesador
60 GB de espacio en disco
Procesador x86/X64 (compatible con procesador ARM, como el chip Apple M1/M2)
Conexión a internet estable
Al agregar claves adicionales a un nodo, lo ideal es que las capacidades del hardware aumenten en consecuencia. Sin embargo, no es obligatorio asignar una máquina distinta a cada llave. Se espera que el sistema sea escalable para acomodar docenas de claves en una sola máquina, y posiblemente más.
Nota: Estos requisitos de hardware están sujetos a cambios.
10. Recompensas estimadas de la red de nodos Centinela
Modelo económico de tokens XAI, consulte: Interpretación de la "Economía de tokens" del proyecto XAI
A continuación se presentan tres escenarios para estimar las recompensas de Xai que podría obtener al ejecutar un nodo Sentry. Estos tres escenarios se basan en los siguientes supuestos:
La suma de XAI y esXAI nunca superará los 2.500.000.000. Dado que el ecosistema Xai es dinámico, es imposible predecir con precisión las recompensas simbólicas mensuales para cada clave Sentry.
El 100% del GAS se quema, por lo que no hay garantía de que la oferta vaya a ser siempre inflacionaria, puede ser deflacionaria.
La Fundación Xai no venderá más de 50.000 claves Sentry (un nodo puede cargar varias claves). Se espera que esto lleve entre 2 y 3 años. Las llaves centinela se vuelven más caras con el tiempo.
El monto mensual de esXAI por clave Sentry también puede fluctuar según la cantidad de participantes en apuestas en el ecosistema.
El significado de las siguientes tres tablas es que, bajo la diferente circulación de tokens XAI y esXAI, la cantidad de claves de nodo activadas en la red y las correspondientes recompensas mensuales esperadas de tokens por clave:
Estimación del escenario A: si hay un total de 750.000 tokens XAI y esXAI en circulación, cada clave Sentry recibirá recompensas esXAI de acuerdo con la siguiente tabla:
Estimación del escenario B: si hay un total de 1.250.000.000 tokens XAI y esXAI en circulación, cada clave Sentry recibirá recompensas esXAI de acuerdo con la siguiente tabla:
Estimación del escenario C: si hay un total de 2.187.500.000 tokens XAI y esXAI en circulación, cada clave Sentry recibirá recompensas esXAI de acuerdo con la siguiente tabla:
Parte 2: XAI es desarrollado y mantenido por Arbitrum (ARB), por lo que tenemos que arrojar algo de luz sobre la arquitectura de Arbitrum:
1.Decisión nitro
Todas las cadenas de Arbitrum se basan en Arbitrum Nitro, que es la tecnología subyacente para todas las cadenas del ecosistema. Nitro ejecuta una versión bifurcada de Geth y utiliza WebAssembly como su máquina virtual subyacente a prueba de fraude.
2.Cualquier decisión de confianza
Anytrust es un protocolo Arbitrum que gestiona la disponibilidad de datos a través de un conjunto de licenciantes llamado Comité de Disponibilidad de Datos (DAC). Este protocolo reduce las tarifas de transacción al introducir un supuesto de confianza adicional con respecto a la disponibilidad de datos, en lugar de utilizar el mecanismo de disponibilidad de datos sin confianza de Ethereum.
3. Introducción a Arbitrum 2 capas que quizás conozcas
Arbitrum Nova es un ejemplo de una cadena AnyTrust; Arbitrum One es otra cadena alternativa que implementa el protocolo Arbitrum Rollup puramente sin confianza (y con mayor uso de gas L1). Ambas cadenas están construidas con Nitro.
4.Cadena de órbita
Arbitrum Orbit permite a terceros crear sus propias cadenas Arbitrum Rollup y AnyTrust autogestionadas. Arbitrum ofrece tecnologías Rollup y AnyTrust para una máxima flexibilidad al crear cadenas Orbit. Como todas las cadenas del ecosistema Arbitrum, tanto Arbitrum Rollups como la cadena Arbitrum Anytrust Orbit se construyen utilizando Nitro como tecnología subyacente.
5. Comprender la situación básica de Xai.
Entendamos a Xai en el contexto anterior. Xai opera como una cadena Arbitrum Orbit, aprovechando la tecnología Anytrust para obtener la máxima velocidad y el mínimo costo. A diferencia de la mayoría de las cadenas Orbit "autónomas", Xai se beneficia del soporte técnico directo de Offchain Labs. ¡Este tipo de soporte es inimaginable para otras cadenas Orbit! y es un componente clave del plan estratégico de Xai dentro del ecosistema Arbitrum.
Parte 3: una vez que tenga los conceptos anteriores, comprendamos mejor la arquitectura:
1.AnyTrust: infraestructura blockchain revolucionaria
Dentro del marco AnyTrust y como una variante de vanguardia de la tecnología Arbitrum Nitro, Offchain Labs aprovecha la innovación para resolver algunos de los desafíos más apremiantes en el espacio blockchain. AnyTrust nos brinda una nueva perspectiva al incorporar supuestos de confianza ligeros, lo que reduce significativamente los costos y al mismo tiempo garantiza una sólida disponibilidad y seguridad de los datos.
2. Reducir costos mediante supuestos de confianza
En el núcleo del protocolo Arbitrum, todos los nodos de Arbitrum (incluidos los validadores que verifican la exactitud de la cadena y apuestan por los resultados precisos) necesitan acceder a los datos de cada transacción de capa dos (L2) en la bandeja de entrada de la cadena Arbitrum. Tradicionalmente, el resumen de Arbitrum garantiza el acceso a los datos mediante la publicación de datos como datos de llamada en la capa uno (L1) de Ethereum, un proceso que genera importantes tarifas de gas de Ethereum, que es un componente importante del costo en Arbitrum.
3.Flexibilidad de los conjuntos de valores
Los Ketsets desempeñan un papel clave en la arquitectura de AnyTrust. Especifican las claves públicas de los miembros del comité y el número de firmas necesarias para verificar el Certificado de disponibilidad de datos (DACert). Los Ketsets brindan flexibilidad para cambiar los miembros del comité y les permiten actualizar sus claves según sea necesario.
4. Certificados de disponibilidad de datos (DACerts)
En AnyTrust, un concepto básico es el certificado de disponibilidad de datos (DACert). Un DACert consta del hash del bloque de datos, un tiempo de vencimiento y una prueba de que los miembros del comité N-1 han firmado el par (hash, tiempo de vencimiento). Esta prueba incluye un hash del conjunto de claves utilizado para la firma, un mapa de bits que indica qué miembros del comité firmaron y una firma agregada BLS en la curva BLS12-381, que demuestra al firmante.
Debido al supuesto de confianza 2 de N, DACert sirve como prueba de que los datos de un bloque estarán disponibles para al menos un miembro honesto del comité hasta un tiempo de vencimiento específico. Esta suposición de confianza es la base para la confiabilidad y seguridad de la disponibilidad de datos dentro del marco AnyTrust.
5.Mecanismo de liberación de datos dual
AnyTrust introduce un método dual para publicar bloques de datos en L1. Además del método tradicional de publicar bloques de datos completos, también permite la emisión de DACerts, que son certificados que acreditan la disponibilidad de los datos. El contrato de bandeja de entrada L1 verifica la validez de los DACerts, incluida la referencia a los Kesets válidos especificados en el DACert.
El código L2 responsable de leer los datos de la bandeja de entrada está diseñado para manejar ambos formatos de datos sin problemas. Cuando se encuentra un DACert, realiza verificaciones de validez, incluida la garantía de que la cantidad de firmantes cumpla con los requisitos de Ketsets, la validación de firmas agregadas y la confirmación de la caducidad más allá de la marca de tiempo L2 actual. Los DACerts válidos garantizan que el bloque de datos sea accesible y pueda ser explotado mediante código L2.
6. Servidor de disponibilidad de datos (DAS)
Los miembros del comité operan el servidor de disponibilidad de datos (DAS), que proporciona dos API clave:
(1) API del clasificador: diseñada para ser utilizada por el clasificador de la cadena Arbitrum, esta interfaz JSON-RPC permite al clasificador enviar bloques de datos a DAS para su almacenamiento.
(2) API REST: diseñado para una mayor accesibilidad, el protocolo basado en RESTful HTTP(S) permite la recuperación de fragmentos de datos mediante hash. Es totalmente almacenable en caché y se puede implementar junto con servidores proxy de almacenamiento en caché o CDN para mejorar la escalabilidad y proteger contra posibles ataques DoS.
7. Interacción clasificador-comité
Cuando el clasificador Arbitrum tiene la intención de publicar un lote de datos a través del comité, envía los datos y un tiempo de vencimiento a todos los miembros del comité en paralelo a través de RPC. Cada miembro del comité almacena los datos, firma el par (hash, tiempo de vencimiento) usando su clave BLS y devuelve la firma y el indicador de éxito al secuenciador. Una vez que se recopilan suficientes firmas, el secuenciador las agrega para crear un DACert válido para pares (hash, tiempo de vencimiento). Este DACert luego se publica en el contrato de la bandeja de entrada L1, lo que lo hace accesible al software de cadena AnyTrust de L2. En el caso de que el secuenciador no pueda recopilar suficientes firmas dentro del período de tiempo especificado, adopta una estrategia de "respaldo al resumen" y publica los datos completos directamente en la cadena L1. El software L2 se destaca por comprender ambos formatos de publicación de datos (a través de DACert o datos completos) y manejar cada formato de manera adecuada. En resumen, AnyTrust, como innovación pionera dentro del ecosistema Offchain Labs, representa un avance crítico para abordar la disponibilidad de datos, la seguridad y la rentabilidad de la infraestructura blockchain. A través de una suposición de confianza sensata y un enfoque novedoso para la publicación de datos, AnyTrust allana el camino para soluciones blockchain más escalables, accesibles y seguras.
Parte 4: Con los conceptos anteriores en mente, ahora expliquemos por qué los ganglios centinela son importantes: el problema de la comprobación del tramposo, por qué el dilema del validador es más difícil de lo que cree y la solución.
El autor es Ed Felten, científico jefe de Arbitrum.
En los sistemas blockchain, un patrón de diseño común es hacer que una de las partes haga algo de trabajo y deposite un depósito en garantía por el comportamiento correcto, y luego invite a otros a verificar el trabajo y retirar este depósito si descubren que el trabajador hace trampa. Se podría llamar el patrón de diseño "afirmar-desafío". Hacemos esto en Arbitrum y recientemente hemos visto propuestas como Optimistic Rollup en las noticias.
Estos sistemas pueden verse afectados por el dilema del validador, que es básicamente la observación de que no tiene sentido verificar el trabajo de alguien si sabes que no hará trampa, pero si no lo haces, tiene un incentivo para hacer trampa; Si usted es diseñador, quiere demostrar que su sistema es compatible con los incentivos, lo que significa que si todos se comportan de manera consistente con sus incentivos, no se producirán trampas. Esta es un área donde la intuición puede llevarte a error. Este problema es mucho más difícil de lo que parece, como veremos cuando analicemos los incentivos de las partes a continuación.
Un modelo súper simple
Comenzamos construyendo el modelo más simple que podamos. Supongamos que hay dos jugadores. Quien afirma hace una afirmación que puede ser verdadera o falsa. El verificador puede verificar la afirmación del afirmador, o puede optar por no hacer nada, presumiblemente bajo el supuesto de que el afirmador probablemente esté diciendo la verdad. Suponemos que el costo de verificación del verificador es C. Si el verificador verifica y descubre que el autor hizo trampa, recibirá una recompensa de R. (R incluye todos los beneficios que obtiene el examinador al descubrir que hace trampa. Esto incluye los beneficios obtenidos "fuera del sistema", así como cualquier beneficio obtenido debido a una mayor confianza en el sistema). Si el afirmador no fue descubierto, al hacer trampa, el verificador pierde L, por ejemplo, porque quien hace trampa puede tomar fraudulentamente artículos valiosos del verificador.
Ahora tenemos dos amenazas de las que preocuparnos: el soborno y la pereza. El soborno es la posibilidad de que quien afirma sobornar al verificador para que no verifique, permitiendo así que el autor haga trampa sin ser detectado. Podemos evitar que esto suceda asegurándonos de que el asertor deposite un depósito muy grande que sea mayor que el valor total en el sistema y pague al verificador cuando se detecte trampa, de modo que el aserdor no esté dispuesto a pagar más que la recompensa R del verificador. soborno. Esto evitará el soborno, pero requiere que el sistema esté totalmente garantizado, lo que puede resultar muy costoso.
Otra amenaza es la pereza, el riesgo de que el verificador decida no comprobar el trabajo del afirmador. (Recuerde, las fichas pueden decir que están comprobando, pero en realidad no lo hacen). Veamos los incentivos para las fichas para ver si ésta es una estrategia razonable.
Supongamos que quien afirma hace trampa con probabilidad X. Ahora, la utilidad del inspector es la siguiente:
Si el revisor marca: RX-C
Si el verificador no marca: -XL
Sólo vale la pena verificar si la utilidad de verificar es mayor que la utilidad de no verificar, es decir, si X > C/(R+L). Aquí están las malas noticias: quien afirma puede hacer trampa aleatoriamente, con una probabilidad menor que C/(R+L), un verificador racional nunca verificará, por lo que nunca será sorprendido haciendo trampa.
Introduzcamos algunos números. Si el coste de comprobar cada transacción es de 0,10 dólares y el verificador recibe una recompensa de 75 dólares si detecta trampas, pero pierde 25 dólares si no detecta trampas, entonces el que afirma puede hacer trampa con impunidad mil veces. Si queremos que este sistema ejecute miles de transacciones, entonces tenemos un gran problema. Obviamente no hay nada que podamos hacer en este modelo para reducir a cero la probabilidad de hacer trampa. Sólo podemos esperar un sistema con exceso de garantías para que el denominador de C/(R+L) sea mayor.
Este es un resultado sorprendentemente sólido, en el mal sentido. No depende en absoluto de los incentivos del afirmador. Siempre que el autor de la afirmación obtenga una ventaja distinta de cero al hacer trampa exitosamente, puede hacerlo con cierta probabilidad, sabiendo que no vale la pena el esfuerzo del verificador por verificar. Este resultado tampoco depende de cuánto tiempo le damos al inspector para completar el trabajo, o si pagamos por el inspector (reclamado). Tal vez ahora estés pensando que el problema es que solo hay un inspector. ¿Agregar más fichas reduciría la probabilidad de hacer trampa? Sorprendentemente, no es así.
Agregar censores no ayuda a prevenir las trampas
Nuevamente, formulemos un modelo más simple. Actualmente hay dos inspectores que actúan de forma independiente. Cada verificador paga a C si verifica, y si alguien verifica y descubre que el autor de la afirmación hace trampa, se paga una recompensa de R al verificador exitoso, o si ambos verificaron, la recompensa se divide en partes iguales entre los dos. (Si lo desea, puede darle a uno de ellos una recompensa completa aleatoria de R en el caso de que todos hagan check. Esto no afecta la estrategia ni los resultados de nadie). Como antes, cada inspector perderá L si el asertor hace trampa sin obtener atrapó.
Sigue siendo cierto que si quien afirma hace trampa menos de C/(R+L) del tiempo, entonces no vale la pena que el verificador verifique porque la utilidad de verificar es menor que la utilidad de no verificar. De hecho, el problema de los incentivos es peor que antes, porque el costo de verificar por inspector sigue siendo C, pero la recompensa esperada por un inspector exitoso que descubre una trampa es menor que R, porque a veces es necesario dividir la recompensa: la recompensa esperada será estar en R/2 y R. Si la recompensa esperada es bR, donde b está entre 0,5 y 1, entonces el autor de la afirmación puede hacer trampa hasta C/(bR+L) del tiempo; ¡esto es más trampa sin ser detectada que si solo hubiera un inspector! (Las matemáticas se vuelven un poco complicadas porque el valor de b depende de la estrategia del corrector, y su estrategia depende de b, pero debe quedar claro que a veces necesitarán dividir la recompensa. Además, el valor efectivo de L también se reduce , dado que uno no las damas no pueden perder su L por ser verificadas por otras damas).
Un aspecto donde sería realmente útil agregar censores es en la prevención del soborno. Con dos fichas, el asertor debe pagar un soborno de más de R a cada asertor, lo que hace que el soborno sea dos veces más caro, lo que permite apostar el 50% en lugar de apostar todo. Pero la contrapartida es que aumenta la cantidad de trampas.
No entraré en todos los cálculos aquí, pero bajo suposiciones razonables, aumentar de una ficha a dos podría resultar en un aumento del 50% en las trampas no detectadas.
¡Agregar censores empeora las cosas!
Puedes agregar más fichas y las cosas empeorarán. A medida que aumenta el número de inspectores, el inspector debe preocuparse más de que la recompensa se divida de múltiples maneras, por lo que la recompensa esperada para cada inspector exitoso disminuye gradualmente, lo que hace que la probabilidad de que el afirmador haga trampa de manera segura aumente gradualmente. Desde esta perspectiva, el peor de los casos es que todos en el mundo puedan convertirse en censores. Esto no es infinitamente malo, ya que las cosas empeoran a medida que se agregan más censores, pero ciertamente no ayudará a prevenir las trampas, incluso si elimina efectivamente el riesgo de soborno.
¿Está seguro de que su sistema es compatible con incentivos?
Si tiene un sistema que se ajusta a este tipo de modelo y cree que es compatible con incentivos, debe pensar detenidamente por qué. En particular, debe explicar por qué el verificador haría el trabajo de verificar, incluso si cree que es poco probable que quien hace la afirmación haga trampa. Simplemente tener una gran penalización por hacer trampa no es suficiente. No basta con tener una recompensa por atrapar a los tramposos. Tener muchas fichas no es suficiente; de hecho, puede empeorar las cosas. ¿Por qué su sistema es inmune?
Este desafío se aplica a sistemas como Optimistic Rollup. Cuando hablamos de Arbitrum, también se aplica a nosotros.
Teniendo en cuenta lo anterior, los métodos tradicionales de verificación de incentivos no logran los resultados deseados: existe una tasa de referencia de trampa por debajo de la cual los verificadores considerarán que la verificación no vale la pena. En conclusión:
Hay dos jugadores, un afirmador, que hace una afirmación, ya sea verdadera o falsa, y un verificador, que puede verificar la afirmación con algún costo computacional. Si el inspector pasa, su utilidad es RX-C, si no pasa, su utilidad es -XL, donde R es la recompensa por detectar trampas, C es el costo de verificar y L es la pérdida del inspector por no detectar trampas. , X es la probabilidad de que el afirmador haga trampa (elegida por el afirmador). Algo de álgebra muestra que si
Para resolver este problema y crear una situación en la que un revisor impulsado por incentivos siempre verificará, tenemos que cambiar los incentivos del revisor. El problema básico es que en el modelo original, los incentivos positivos para que las fichas pasen son todos proporcionales a Si queremos un incentivo de verificación que funcione independientemente, necesitamos crear un incentivo de verificación o un desincentivo para no verificar que sea independiente de las acciones de quien afirma.
TrueBit intenta hacer esto agregando afirmaciones intencionalmente falsas al conjunto de afirmaciones, esencialmente reemplazando X con X más una constante. Hay algunos problemas con este enfoque. (El artículo original de Arbitrum tiene una sección sobre las cuestiones de motivación de TrueBit).
Centrarse en los desafíos
Utilizamos un enfoque diferente al que llamamos centrarse en el desafío. La idea es que si quien afirma está calculando un valor f(x), primero emite x y un desafío criptográfico. Para responder correctamente al desafío, el examinador necesita conocer f(x). Sólo después de que se haya producido el desafío, el autor de la afirmación publica f(x); en este punto, el verificador ya ha hecho el arduo trabajo de calcular f(x), por lo que no tiene ningún incentivo para ser perezoso. (Más detalles sobre el acuerdo a continuación).
Para reducir la cantidad de transacciones en cadena que esto requiere, arreglaremos las cosas de manera que la respuesta correcta a un desafío por parte de un inspector sea generalmente el silencio. Pero en casos raros, el verificador debe publicar una transacción muy pequeña en la cadena. Si el corrector da la respuesta incorrecta (silencio cuando se debe soltar, o silencio cuando se debe soltar), perderá un pequeño depósito.
Adaptemos el modelo de incentivos original para incorporar desafíos de atención. Necesitamos dos nuevos parámetros (los cuales podemos elegir): P, el porcentaje de veces que se publica la respuesta correcta del verificador, y A, la penalización si el verificador da una respuesta incorrecta. Ahora, la utilidad del inspector es:
Si está marcado: RX-C
Si no, marque: -LX-PA
La observación clave es que mientras PA > C, entonces verificar es la estrategia óptima, sin importar cuál sea X (la probabilidad de hacer trampa).
Costo muy bajo
Para evaluar el coste, veamos un ejemplo concreto. Supongamos que hay una afirmación cada cinco minutos y el costo de la verificación es de $0,001. Si fijamos la probabilidad P en 0,3%, el verificador tendrá que pagar un depósito de 3 dólares. Ahora, el costo por afirmación del verificador es de $0,0003 en tarifas de gas (la tarifa de gas de $0,10 por publicar su respuesta no silenciosa, multiplicada por la probabilidad del 0,3% que tiene de publicar), más alrededor de $0,0003 para bloquear su apuesta de $3 durante cinco minutos. El costo de interés es de $0,0006 por afirmación.
Ampliación para varios inspectores
El desafío del enfoque se adapta bien con varios examinadores. El protocolo emite un desafío que afecta a cada verificador de manera diferente, lo que obliga a cada verificador a calcular f(x) por sí solo. Cada verificador experimentará el mismo costo (en nuestro caso, $0,0006 por afirmación).
En un sistema abierto, cualquiera es elegible para verificar los cálculos y usted puede permitir que cualquiera se registre como verificador y realice el pequeño depósito requerido. Esto los hará elegibles para recibir desafíos de atención y potencialmente recibir una compensación de los desarrolladores de dapp. Cualquiera puede cuestionar las afirmaciones incorrectas de quien afirma, pero sólo los examinadores registrados enfrentan desafíos de atención.
Detalles técnicos del acuerdo
Ahora que entendemos lo que puede hacer por nosotros centrarnos en los desafíos, profundicemos en los detalles técnicos de cómo funcionan.
Cada verificador tiene una clave privada k y la clave pública correspondiente gᵏ, definidas en un grupo apropiado. Todos conocen la clave pública de cada verificador. También nos basaremos en una función hash H adecuada.
Para cuestionar el cálculo de f(x), donde la función f se conoce de antemano, el afirmador genera un valor aleatorio r y luego emite (x, gʳ) como desafío.
Un verificador que posea una clave privada k debería responder al desafío publicando una pequeña transacción solo si H(gʳᵏ, f(x)) < T, donde T es un umbral elegido adecuadamente. Tenga en cuenta que sólo el asertor (que conoce r) y ese verificador en particular (que conoce su clave privada k) pueden calcular el hash, ya que son los únicos que pueden calcular gʳᵏ. También tenga en cuenta que calcular el hash requiere conocer f(x).
Después de que los inspectores hayan tenido algo de tiempo para publicar sus respuestas al desafío, el autor de la afirmación puede publicar su f(x) y, si algún inspector no está de acuerdo con ella, será cuestionado como de costumbre. En este punto, el afirmador puede acusar a cualquier verificador de respuestas incorrectas; el afirmador debe emitir r para fundamentar su acusación. El minero o el contrato pueden verificar si la acusación es correcta y castigar al infractor, pero si la afirmación de f(x) del autor no se acepta en última instancia como correcta, la acusación será ignorada. Si se multa a algún verificador, el que lo afirma recibirá la mitad de los fondos confiscados y la otra mitad será destruida.
Este enfoque proporciona al examinador los incentivos adecuados. Saber cómo debe responder un inspector a un desafío requiere conocer la clave privada de ese inspector y f(x), por lo que cada inspector querrá calcular f(x). A menos que el verificador calcule f(x) por sí mismo, no puede aplicar el protocolo de forma segura. Las respuestas de otros verificadores no son útiles para determinar f(x) porque dependen de las claves privadas de esos verificadores. Si un verificador depende de que otra persona le diga f(x), no tiene forma de verificar ese valor reclamado (aparte de calcular f(x) en sí), y el verificador corre el riesgo de ser penalizado si se equivoca. Incluso existe un incentivo para que una de las partes intente engañar al verificador acerca de f(x); es decir, el afirmador, que se beneficia del error del verificador y puede utilizar estas ganancias para sobornar a los "amigos" del verificador para que le proporcionen información incorrecta. .
Optimización y conclusión.
Existen varios trucos para hacer más efectivo este protocolo. Por ejemplo, podríamos agrupar una afirmación con el siguiente desafío en una transacción en cadena para que el desafío no aumente la cantidad de transacciones. Si P es pequeño (por ejemplo, 0,3% en nuestro ejemplo) y el número de verificadores no es muy grande, entonces los verificadores rara vez necesitan escribir transacciones en la cadena, por lo que el impacto general del protocolo en la cantidad de transacciones en la cadena será ser el más pequeño.
Con una implementación inteligente, el costo de este protocolo debería ser muy bajo en comparación con el costo inicial de emitir afirmaciones en cadena. En nuestro caso, agregar desafíos de atención al protocolo de desafío de afirmación existente aumenta el costo total en menos del 1%.
Y las ganancias son sustanciales: obtenemos un protocolo de verificación compatible con incentivos que es inmune al dilema del validador. Mientras al menos un verificador sea racional, las afirmaciones del afirmador siempre serán verificadas.
Para obtener más información sobre el proyecto, consulte: Cadena pública de juegos Xai: base de datos de Binance Square
