Algunas decisiones pueden automatizarse.

Cuantos más jueces consultes, menor es la probabilidad de que el panel se aparte del lado que prefiere todo el conjunto.

Cuanto mayor es el acuerdo dentro del conjunto, menos jueces hacen falta para un resultado estable.

No. Significa que los paneles elegidos al azar tienden a coincidir con el conjunto declarado. La verdad es una cuestión aparte, y empírica.

El paper calcula el error exacto en el peor caso cuando una proporción conocida del conjunto está corrompida antes de sortear el panel. La tolerancia se mide, no se supone.

No, es ilustrativa. Los contratos reales de GenVM son clases de Python que se ejecutan aisladas, pero el mecanismo —un criterio declarado por llamada para cada operación de IA— es exactamente el que especifica el whitepaper.

Sus propias reejecuciones llegan honestamente al veredicto contrario. Eso es discrepancia, no trampa: nunca se castiga, y la estadística de Fiabilidad está pensada para absorberla.

El desarrollador del contrato, en cada llamada. Distintas llamadas de un mismo contrato pueden declarar criterios distintos.

En las llamadas a una IA y en las lecturas de la web no hay un único resultado correcto: dos resúmenes correctos difieren en las palabras. El código determinista se sigue comprobando byte a byte.

La mayoría de las decisiones se resuelven barato. Añade jueces solo cuando el beneficio supere al coste.

Cuando hay bastante en juego, o la evidencia es lo bastante débil, como para pagar otra mirada.

Compran cosas distintas: volver a comprobar añade evidencia sobre la misma respuesta; regenerar cambia la respuesta misma. El paper pone precio a cada opción antes de gastar.

Aquí no se demuestra. La regla es un ideal de referencia; la red solo lo alcanza si a alguien le compensa en privado presentar la apelación adecuada. Eso es justamente lo que estudia Incentivos.

Dos flujos: las comisiones de transacción y una emisión que baja del 9% hacia el 4% siguiendo una curva fija (un techo; las quemas solo pueden rebajarlo). La DAO se financia solo con comisiones, así que sus ingresos siguen el uso real.

El error honesto y la mala conducta tienen precios distintos. Perder una votación solo quema cantidades del tamaño de una comisión, nunca el principal. La inactividad penaliza un 1%, el fraude demostrable penaliza al líder un 5%, y una apelación fallida pierde su fianza. La discrepancia se absorbe; la mala conducta se castiga.

No, y el paper lo dice. El peso cóncavo solo amortigua la concentración; lo que impide fragmentarse es que cada identidad tiene que bloquear los 42.000 GEN completos, mantener su propio nodo y exponerse a su propia penalización.

Sí. Delega 42 GEN o más y las recompensas se recomponen solas. No hay comisiones que comparar: el protocolo fija el reparto, y cada GEN en la posición de un validador rinde lo mismo.

Sus probabilidades de ganar, la recompensa, la fianza en riesgo, lo que cuesta apelar y cualquier interés privado en el resultado.

Bajo ciertas condiciones, sí. El paper muestra cómo calibrar las recompensas para que el interés privado siga de cerca los casos en que al sistema le conviene otro panel.

En cuanto muchas personas pueden apelar, sus decisiones interactúan: esperar, competir por llegar primero, duplicar esfuerzo. El mecanismo tiene que poner precio a las tres cosas.

Una fianza mayor financia el panel y disuade el spam, pero inmoviliza capital: las cuentas del beneficio pueden seguir siendo idénticas mientras el grupo de personas que puede permitirse apelar se reduce drásticamente.

Un modelo por capas: un grafo de estados canónico, especificaciones TLA+ comprobadas contra él y una correspondencia entre cada transición y el código Solidity de una revisión fijada.

No. Demuestra propiedades declaradas sobre un modelo declarado de una revisión fijada. Precisamente ese acotamiento es lo que hace que las afirmaciones se puedan comprobar.

El protocolo sigue evolucionando. Cada revisión se vuelve a comprobar contra las mismas propiedades, así que una desviación silenciosa aparece como una comprobación fallida y no como una incidencia en producción.

Sí: la condición de carrera y los tres invariantes rotos que se mencionan arriba. Todos confirmados en la implementación y comunicados al equipo.