Esta es la segunda parte de una publicación que, por su extensión, decidimos dividir en dos partes, y que explora el diseño de The Graph Network. Puedes leer la primera parte aquí.
En la primera publicación, hicimos una descripción general de lo que es The Graph Network, cómo se verá desde la perspectiva del usuario final y cómo funciona a un alto nivel.
En esta publicación, profundizaremos en varios conceptos clave, incluido cómo se utilizan los tokens THE GRAPH (GRT) para la participación en el indexador, la curación y las recompensas del indexador. También presentaremos Graph Explorer, una dApp para interactuar con The Graph Network, y describiremos las capas de pagos y verificación. Si te parece interesante la propuesta, sigue leyendo!
Replanteo de indexador
The Graph adopta un modelo de token de trabajo , donde los indexadores deben bloquear (staking) tokens GRT para vender sus servicios en el “Query Market”, del que ya hablamos en el anterior artículo. Esto tiene dos funciones principales:
- Proporcionar seguridad económica, ya que la TRB bloqueada puede reducirse si los indexadores realizan su trabajo de forma maliciosa. Una vez bloqueados en un nodo los tokens GRT, solo se pueden retirarse tras un período de descongelación , lo que brinda el tiempo suficiente para la verificación y la resolución de disputas.
- Proporciona un mecanismo de resistencia de ataque tipo Sybil . Tener indexadores falsos o de baja calidad en un subgraph determinado hace que sea más lento encontrar proveedores de servicios de calidad. Por esta razón, se quiere que todos los indexadores estén claramente visibles y sin máscaras que puedan ocultar posibles intenciones maliciosas en contra de la red.
Para que los mecanismos anteriores funcionen correctamente, es importante que se incentive a los indexadores a mantener GRT aproximadamente en proporción a la cantidad de trabajo útil que están haciendo en la red.
Un enfoque ingenuo sería intentar que cada GRT apostado dé derecho a un indexador a realizar una cantidad específica de trabajo en la red. Hay dos problemas con esto: primero, establece un límite superior arbitrario en la cantidad de trabajo que la red puede realizar; y en segundo lugar, es casi imposible poder cumplir esta premisa de manera escalable, ya que requeriría que todo el trabajo se coordine centralmente en la cadena.
Un mejor enfoque para esto es aplicar lo que acertadamente se hizo en el proyecto 0x, que consiste en cobrar una tarifa de protocolo en todas las transacciones, la cual es posteriormente reembolsada a los participantes proporcionalmente a su participación y las tarifas cobradas por la red, utilizando el Función de producción Cobb-Douglas .
En el modelo de The Graph la proporción del pool rebaja Y i un indexador que reciba durante un período de tiempo es
donde ω ij es la cantidad de participación que el Indexador i ha asignado al subgraph j , Ω es la cantidad total apostada en la red, θ ij es la cantidad de tarifas de consulta que el Indexador i ha generado para el grupo de reembolsos en el subgrafo j y Θ es el Importe total de las tarifas de consulta recaudadas por el protocolo.
Recomiendo leer el artículo , pero lo que es interesante el propósito de The Graph es que, en equilibrio, se esperaría que un tomador de decisiones racional presupuestara una proporción estable de su gasto entre los dos insumos de la función de producción. En caso de The Graph, ese sería el costo de los tokens GRT necesarios, así como los gastos operativos relacionados con la ejecución de un nodo gráfico que permite a un indexador realizar más trabajo y, por extensión, cobrar más tarifas de consulta para la red.
Debido a que esperaríamos que todos los indexadores racionales tomaran una decisión presupuestaria equivalente, en equilibrio, deberíamos esperar que los indexadores apuesten una proporción del total de GRT apostado, igual a la proporción de trabajo que han realizado para la red.
La belleza es que esta distribución de participación no necesita ser aplicada en el protocolo, sino que surge naturalmente, ya que los indexadores toman decisiones en su propio interés económico.
Delegación
Para los titulares de tokens GRT que no desean venderlos, pero quieren darles un uso productivo para asegurar la red, el protocolo ofrece la posibilidad de delegarlos.
Un delegador puede “prestar” sus GRT a un indexador, a cambio de una parte de sus tarifas de consulta y recompensas del indexador, según lo especificado por el indexador.
Además de aumentar la participación de los tokens, la delegación presenta una oportunidad para que los indexadores más pequeños y con limitaciones de capital sean más competitivos en la red descentralizada al proporcionar una alta calidad de servicio y atraer delegados.
Una decisión importante que deben tomar los protocolos de participación con respecto a la delegación es si la participación delegada puede reducirse debido a las malas conductas de algún indexador. En The Graph, la participación delegada no se podrá reducir, porque esto fomenta una relación de confianza entre los delegados y los indexadores que podría llevar a una mecánica de “el ganador se lleva todo” y por tanto dañar la descentralización que busca el proyecto.
Al igual que en otros protocolos que funcionan de este mismo modo, The Graph impone un límite sobre la cantidad de participación delegada que un indexador puede aceptar por cada unidad de su propia participación. Esta “capacidad de delegación” asegura que un indexador siempre esté poniendo en juego una cantidad mínima de sus propios fondos para poder participar en la red.
Señalización del curador
Para que un consumidor pueda consultar un subgraph, primero se debe indexar el subgraph, un proceso que puede llevar horas o incluso días. Si los indexadores tuvieran que adivinar a ciegas qué subgraphs deberían indexar por si acaso ganaran tarifas de consulta, el mercado no sería altamente ineficiente.
La elección del curador es el proceso de depositar TRB en una curva de vinculación para un subgraph, para, de este modo, elegir a los indexadores a los que el subgraph debe indexarse.
Los indexadores pueden confiar en la señal porque cuando los curadores depositan GRT en la curva de vinculación, reservan una parte de curación para el subgraph respectivo, lo que les da derecho a una parte de las tarifas de consulta futuras recaudadas en ese subgraph.
El uso de curvas de vinculación, un tipo de Market Maker Algorítmico en el que el precio está determinado por una función, significa que cuantas más acciones de curación se realicen, mayor será el tipo de cambio entre TRB y las acciones de curación. Por lo tanto, los curadores exitosos podrían obtener ganancias de inmediato si sienten que el valor de las futuras tarifas de curación se ha fijado correctamente. De manera similar, deberían retirar sus aportaciones si consideran que el mercado hace una sobrevaloración de las acciones de curación y por tanto no les sale rentable operar en la red.
Esta dinámica significa que la cantidad de GRT dirigida hacia un subgraph debe proporcionar una señal de mercado continua y valiosa en cuanto a la predicción del mercado para el volumen de consultas futuras en dicho subgraph.
Recompensa de indexador
Otro mecanismo que empleamos relacionado con la participación del indexador y la señalización del curador es la recompensa del indexador.
Esta recompensa, que se paga mediante la emisión de nuevos tokens, tiene como objetivo incentivar a los indexadores a indexar subgrafos que aún no tienen un volumen de consultas significativo. Esto ayuda a resolver el problema de bootstrapping para nuevos subgráficos, que pueden no tener una demanda preexistente para atraer a los indexadores.
La forma en que funciona es que a cada subgrafo de la red se le asigna una parte de la emisión total de tokens de la red, en función de la cantidad proporcional de señal de curación total que tiene el subgrafo. Esa cantidad, a su vez, se divide entre todos los indexadores apostados en ese subgrafo proporcionalmente a su cantidad de participación aportada.
Más formalmente, la recompensa por inflación del indexador para el indexador i es
donde ω ij es la cantidad que el indexador i ha apostado en el subgrafo j, Ω j es la cantidad total apostada en el subgrafo j, ψ j es la cantidad de TRB señalada para el subgrafo j, Ψ es la cantidad total señalada en la red y Φ es la recompensa total del indexador de la red denominada en TRB.
SSestablecer la tasa de emisión de forma dinámica de manera óptima es un área de investigación en curso, pero basta con decir que será baja, probablemente de un solo dígito.
Este mecanismo proporciona un incentivo adicional para que los indexadores respondan a la señal proporcionada por los curadores, lo que hace que la curación sea una actividad aún más útil para participar.
Indexación verificable
Dada la subvención del protocolo de la indexación de subgrafos a través de la recompensa del indexador, es importante que el mecanismo se utilice para subvencionar el trabajo útil. Para ello, presentamos Pruebas de indexación y un Oracle de disponibilidad de subgrafos.
La intención de ambos mecanismos es mitigar posibles ataques económicos en los que un indexador intenta obtener la recompensa del indexador sin proporcionar un trabajo útil a la red. Esto podría tomar las siguientes formas:
- En realidad, no indexa un subgrafo en el que está recolectando recompensas.
Para mitigar el n. ° 1 y algunas instancias del n. ° 2, el protocolo presenta pruebas de indexación. En su forma actual, estos son simplemente una firma sobre un resumen de mensaje que se genera durante la indexación de un subgráfico de génesis. Cada vez que se actualiza el estado de un subgrafo, también lo hace el resumen del mensaje.
Cuando un indexador va a reclamar su recompensa de indexador en un subgrafo determinado, debe proporcionar una Prueba de indexación reciente para reclamar la recompensa. Debido a que la prueba de indexación (PoI) se calcula a partir de la firma del indexador, cada indexador debe enviar un PoI que sea específico para ellos. Dado que los indexadores compiten por las recompensas de los indexadores en un subgráfico determinado, no es lo mejor para los indexadores coludirse para ayudarse entre sí a generar puntos de interés correctos sin realmente hacer el trabajo.
Estos puntos de interés se aceptan de manera optimista, ya que desbloquean recompensas de inmediato, pero se pueden usar más tarde para cortar un indexador si se descubre que están formados incorrectamente. Las condiciones de tala podrían incluir fallas atribuibles determinísticamente, tales como:
- Un punto de interés que representa un estado incorrecto de un subgrafo
- Proporcionar un punto de interés en un subgrafo no válido
En la primera versión de la red, un Árbitro establecido a través de la gobernanza decidirá las disputas y tiene el poder de terminarlas en “empate” si una falla no es claramente atribuible, o si fue el resultado de un error de software en lugar de un comportamiento malicioso por parte de el indexador. Las decisiones de un Árbitro se basarán en la especificación del protocolo, así como en una “carta de arbitraje” que describe cómo deben resolverse las disputas.
Otro tipo de falla, que es completamente subjetiva debido a la equivalencia de falla entre el hablante y el oyente , es si un manifiesto de subgrafo está disponible o no. Si un manifiesto de subgrafo no está disponible, entonces se vuelve imposible para un Árbitro resolver cualquiera de las otras disputas para ese subgrafo, y también se vuelve imposible para otros Indexadores competir por recompensas de indexador en ese subgrafo.
Para este caso de uso, presentamos un Subgraph Availability Oracle, también establecido a través de la gobernanza. El oráculo examinará varios puntos finales de IPFS destacados, como la puerta de enlace IPFS de Cloudflare, para determinar si un manifiesto de subgrafo está disponible. Si un manifiesto de subgrafo no está disponible, entonces ese subgrafo correspondiente no será elegible para ninguna recompensa de indexación.
Explorador de gráficos y servicio de nombres de gráficos
Seleccionar subgrafos para indexadores es solo la mitad de la historia cuando se trata de sacar a la luz subgrafos valiosos. También queremos mostrar subgrafos valiosos para los desarrolladores.
Ésta es una de las propuestas de valor centrales de The Graph: ayudar a los desarrolladores a encontrar datos útiles sobre los que construir y facilitar la incorporación de datos de una variedad de protocolos subyacentes y fuentes de datos descentralizadas en una sola aplicación.
Actualmente, los desarrolladores logran esto navegando a Graph Explorer:
En The Graph Network, Graph Explorer será una dApp, construida sobre un subgráfico que indexa los contratos inteligentes del protocolo de Graph (¡meta, lo sé!), Incluido el Graph Name Service (GNS) , un registro de subgráficos en cadena.
Un subgrafo se define mediante un manifiesto de subgrafo , que es inmutable y se almacena en IPFS. La inmutabilidad es importante para tener consultas deterministas y reproducibles para verificación y resolución de disputas. El GNS desempeña un papel muy necesario al permitir que los equipos agreguen un nombre a un subgrafo, que luego se puede usar para señalar “versiones” consecutivas de subgrafos inmutables.
Estos nombres legibles por humanos, junto con otros metadatos almacenados en el GNS, permiten a los usuarios de Graph Explorer tener una mejor idea del propósito y la posible utilidad de un subgráfico de una manera que una cadena aleatoria de caracteres alfanuméricos y un código de bytes WASM compilado no .
En The Graph Network, descubrir subgrafos útiles será aún más importante, ya que una futura actualización propuesta del protocolo es la composición de subgrafos. En lugar de simplemente permitir que las dApps se basen en múltiples subgrafos, la composición de subgrafos permitirá crear subgrafos completamente nuevos que hagan referencia directamente a entidades de subgrafos existentes.
Esta reutilización de los mismos subgrafos en muchas dApps y otros subgrafos es una de las eficiencias centrales que The Graph desbloquea. Compare este enfoque con el estado actual del mundo en el que cada nueva aplicación implementa su propia base de datos y servidores API, que a menudo se subutilizan.
Migración de señales
El Graph Name Service (GNS) también expone la funcionalidad de curación. Sin embargo, en lugar de señalizar en subgrafos inmutables, como es el caso en el protocolo central, el GNS admite la señalización en nombres de subgrafos mutables. Los tokens que se señalan en el nombre de un subgrafo se migran automáticamente a la última versión cuando el propietario del subgrafo actualiza las versiones. Esto es similar a delegar una señal al propietario de un subgrafo con nombre (que no debe confundirse con delegar participación a un indexador).
Esto puede proporcionar un beneficio tanto para los Curadores como para los desarrolladores de subgrafos. El desarrollador de subgrafos puede atraer a más indexadores para indexar su nueva versión de subgrafo de lo que podrían hacerlo con solo su propia señal. Mientras tanto, se garantiza que los Curadores siempre estarán señalizados en la versión a la que el desarrollador del subgrafo tiene la intención de dirigir el tráfico de consultas.
Sin embargo, también existen riesgos al señalar con un nombre. Primero, hay un impuesto de curación que se cobra tanto al curador como al propietario del subgrafo en la actualización. Normalmente, este impuesto solo lo paga el Curador en depósito, pero el Curador tiene el control de cuándo señalan y desaniman. Si bien no sería lo mejor para el propietario de un subgrafo actualizar repetidamente las versiones, si se ven obligados a hacerlo, por ejemplo, para corregir errores en su subgrafo, esto agotaría una parte de la señal de los Curadores en cada migración.
Otro riesgo es que el propietario del subgrafo no tiene el control de la fuente principal de tráfico de consultas en el subgrafo. En ese caso, un curador cuya señal se migra automáticamente a una nueva versión puede perder una parte de las tarifas de consulta que aún se envían a una versión anterior del subgrafo.
Micropagos condicionales
Nuestra capa de pagos está diseñada para minimizar la confianza entre el consumidor y el indexador. Los canales de pago son una tecnología que se ha desarrollado para pagos escalables, fuera de la cadena y minimizados por la confianza. Implica dos partes que bloquean los fondos en cadena en un depósito en garantía donde los fondos solo se pueden usar para intercambiar fondos fuera de la cadena entre ellos hasta que se envíe una transacción en cadena para retirar fondos del depósito en garantía.
Tradicionalmente, los diseños de canales de pago han enfatizado el envío seguro de un micropago fuera de la cadena sin tener en cuenta si el servicio o el bien pagado se recibió o no.
Sin embargo, se ha trabajado un poco hacia los intercambios atómicos de micropagos por algún bien digital o computación subcontratada, que desarrollamos aquí. Llamamos a nuestra construcción WAVE Locks . WAVE significa trabajo, atestación, verificación, vencimiento y el diseño general es el siguiente:
- Trabajar . Un consumidor envía un micropago bloqueado con una descripción del trabajo a realizar. Esta especificación del trabajo actúa como bloqueo del micropago.
- Atestación . Un proveedor de servicios responde con el bien o servicio digital que se solicita junto con una certificación firmada de que el trabajo se realizó correctamente. Esto desbloquea el micropago de manera optimista, asumiendo que la certificación es correcta.
- Verificación . La atestación se verifica mediante algún método de verificación. Puede haber sanciones, como cortes, por dar fe de un trabajo que se realizó incorrectamente. La verificación de la atestación se realiza fuera del canal.
- Vencimiento . El proveedor de servicios debe recibir una confirmación de recepción del consumidor o enviar su certificación en cadena para recibir su micropago antes de que expire el micropago bloqueado.
El uso de cerraduras con canales de pago no es nuevo. Tanto los artículos de Lightning como de Raiden discuten el uso de una preimagen hash para desbloquear un micropago. Esto es particularmente útil para micropagos de múltiples saltos donde cada “salto” está bloqueado con el mismo hash y puede ser desbloqueado por un valor, la preimagen, que produce ese hash cuando se ingresa a una función de hash especificada.
Ejemplo de canales de pago de varios saltos que utilizan una preimagen hash para desbloquear los pagos.
Si bien podríamos lanzar nuestra propia solución de canal de pago, que está especialmente diseñada con este nuevo mecanismo de bloqueo, una solución más pragmática es usar canales estatales.
Podemos pensar en los canales estatales como canales de pago, lo que las cadenas de bloques de contratos inteligentes como Ethereum son para Bitcoin. Pueden manejar el caso de uso de pagos simples, pero también pueden codificar transiciones de estado más complejas mientras mantienen las mismas propiedades de escalabilidad y seguridad que un canal de pago.
Sin embargo, lo que los canales estatales y de pago tienen en común es que, en su forma más básica, son un medio de intercambio de valor o actualizaciones de estado entre dos participantes, que se conocen de antemano. Como se mencionó anteriormente con los micropagos de múltiples saltos, el envío entre dos participantes requiere poder formar una cadena de canales de pago entre varios otros participantes, lo que conecta a los dos participantes originales.
El protocolo Graph admitirá a consumidores e indexadores que se conecten a través de canales directos o mediante una red de nodos de canales estatales como se muestra arriba. Para simplificar, las implementaciones de cliente predeterminadas en el lanzamiento utilizarán canales directos.
Una ventaja de tener una red de canales estatales disponible, además de los beneficios de escalabilidad, es que los consumidores pueden utilizar creadores de mercado externos a la cadena para comprar GRT a cambio de ETH o la moneda estable de su elección, justo a tiempo para pagar las consultas. . Esto reduce el riesgo de balance para los consumidores que prefieren mantener un activo cuyo valor no fluctúa.
Verificación de consultas
Para que la construcción de WAVE Locks y el replanteo del indexador sean significativos, debe haber un mecanismo de verificación eficaz que sea capaz de reproducir el trabajo realizado por un indexador, identificando fallas y cortando los indexadores infractores.
En la primera fase de The Graph Network, esto se maneja a través de un proceso de resolución de disputas en cadena, que se decide mediante arbitraje.
Para consultas, apoyamos dos tipos de disputas:
- Disputas de atestación única
- Disputas contradictorias de atestación
En disputas de atestación única , los pescadores presentan disputas junto con una fianza, así como una atestación firmada por un indexador. Si se descubre que el indexador ha dado fe de una respuesta incorrecta a la consulta, el pescador recibe una parte de la cantidad recortada como recompensa. Por el contrario, la fianza del pescador se pierde si la disputa no tiene éxito.
Es importante destacar que la recompensa del pescador debe ser menor que la cantidad recortada. De lo contrario, los indexadores malintencionados podrían simplemente cortarse a sí mismos para sortear los períodos de descongelación o evitar que alguien más los corte.
Para las disputas de atestación única, se supone que Fisherman es un actor que se metió en sus manos a través de algunos medios extraprotocolos, por ejemplo, un servicio de registro de terceros.
Esperamos que el caso de uso mucho más común sean las disputas de certificación en conflicto . En este caso, un pescador puede enviar dos atestaciones para la misma consulta, firmadas por dos indexadores diferentes. Si las atestaciones no concuerdan entre sí, entonces se garantiza que uno o ambos indexadores cometieron un error.
Los consumidores, al consultar The Graph, pueden optar por consultar de forma intermitente a varios indexadores para obtener los mismos resultados de la consulta, para mayor seguridad y la posibilidad de ganar una parte de su participación reducida como recompensa. Esta estrategia funciona mejor a medida que aumenta el número de indexadores únicos en un subgráfico.
En la primera versión de la red, habrá un árbitro establecido a través de la gobernanza del protocolo, que decidirá el resultado de las disputas. De manera similar a las disputas de indexación, el Árbitro puede ejercer su juicio cuando pueden surgir consultas incorrectas como resultado de errores en el software, eventos que faltan a los indexadores de la cadena de bloques u otros factores accidentales que podrían dar lugar a una infracción punible. El arbitraje debe resolver las disputas de acuerdo con la especificación del protocolo, así como con la carta de arbitraje antes mencionada.
Con el tiempo, a medida que el software madure, se esperará que los indexadores desarrollen el conocimiento operativo para evitar este tipo de errores.
Trabajo futuro
Después del lanzamiento de la red, el equipo central de The Graph pasará su manto como administradores únicos del protocolo a la gobernanza descentralizada en cadena llamada The Graph Council. Puede obtener más información al respecto en esta publicación de blog , pero el TLDR es que las mejoras futuras del protocolo pasarán por un proceso de propuesta descentralizado en el que seremos participantes activos.
El trabajo futuro que se describe a continuación representa una visión para el protocolo que defenderemos como participantes en ese proceso descentralizado, pero no es una garantía del camino que tomará el protocolo, que en última instancia depende de las partes interesadas del protocolo.
Composición del subgrafo
Debería ser posible consultar las relaciones entre entidades en los subgrafos y también crear subgrafos que procesen datos de otros subgrafos. Esto hará para la capa de datos abiertos de Web3 lo que los contratos inteligentes y los “legos de dinero” hicieron para DeFi.
Soporte multi-blockchain
El servicio alojado de Graph actualmente admite varias cadenas y capas 2 compatibles con Ethereum, pero el protocolo Graph que se implementa en la red principal de Ethereum inicialmente solo admitirá la indexación de la red principal de Ethereum. Asegurarse de que los incentivos del protocolo puedan funcionar, sin ser jugables, para indexar y atender consultas en otras cadenas es un área de investigación futura.
Verificación optimista de estilo Rollup / Truebit para pruebas de indexación
La mayor parte del trabajo de indexación de un subgrafo ya se realiza en WASM o en un lenguaje que se pueda compilar en WASM. Esto se presta a calcularlos de forma verificable en la capa 2, utilizando alguna forma de protocolo de bisección y juego arbitrado como se hace en Optimistic Rollup y Truebit. Esto nos permitiría eliminar el papel del Árbitro en la indexación de disputas.
Consultas verificables
En lugar de depender del arbitraje para resolver disputas de consultas, la validez de las consultas podría garantizarse mediante pruebas criptográficas. Un buen primer paso aquí sería implementar pruebas de indexación verificables como se discutió en el párrafo anterior. Esto sienta las bases para que el diseño de los puntos de interés evolucione de ser una simple firma sobre un resumen, a ser una entrada útil para verificar consultas, como un compromiso polinomial, un árbol Merkle o alguna otra estructura de datos autenticada.
Resumen optimista / Capa 2 para la economía del protocolo
El uso actual de los canales estatales por parte del protocolo hace que la red sea bastante robusta ante el aumento de los costos del gas Ethereum y significa que los costos del gas no aumentarán drásticamente a medida que aumente el uso de la red. Dicho esto, existen beneficios de poder establecer canales estatales con mayor frecuencia y hacer que los cálculos de recompensa se ejecuten con mayor regularidad, lo que sería factible en una cadena de capa 2.
Mutaciones GraphQL
Las mutaciones GraphQL proporcionan una forma más semánticamente significativa de interactuar con un protocolo que una ABI de contrato inteligente que es de nivel inferior y cuyos métodos no siempre se asignan a una sola acción conceptual. La combinación de mutaciones GraphQL con subgráficos hará que sea mucho más fácil para un nuevo desarrollador comenzar a interactuar con protocolos en cadena, de la misma manera que The Graph ya ha bajado el listón para consumir datos de dichos protocolos.
API GraphQL V2
Hay un puñado de mejoras que hemos identificado en función de las necesidades de los desarrolladores de subgrafos. Estos incluyen paginación más eficiente, clasificación anidada y filtrado y funcionalidad de análisis, como agrupamiento de series de tiempo.
Modelado y simulación de protocolos
Continuaremos construyendo sobre el trabajo iniciado a principios de este año en colaboración con el equipo de BlockScience para modelar mejor el protocolo y simular diferentes opciones de parámetros de protocolo y posibles actualizaciones. Los datos que se están recopilando actualmente como parte de la red de prueba de Mission Control actualmente activa serán fundamentales en este proceso.
Política monetaria automatizada
En la primera versión de la red, la tasa de emisión de Graph Tokens que se utiliza para pagar las recompensas del indexador se establece a través de la gobernanza. A largo plazo, nuestro objetivo es reducir al máximo la superficie de gobernanza. El trabajo de modelado y simulación mencionado anteriormente será útil para ese fin. La política monetaria, con su potencial para beneficiar a ciertas partes interesadas sobre otras, es un objetivo maduro para una regla automatizada que elimina el control de la gobernanza, manteniéndose en línea con el principio rector de The Graph de “minimización progresiva” introducido en la publicación introductoria del blog de The Graph Council.
COLABORA CON EL CANAL
Recuerda que comparto todo este trabajo de manera gratuita. Si quieres mostrar tu agradecimiento el canal lo único que te pido es que te registres en la newsletter y a nuestro canal de Youtube.
Otras maneras de colaborar con nosotros de manera indirecta es comprando los artículos comentados, o bien registrándote en los exchanges y distintas plataformas, a través de los enlaces que hemos dejado en los artículos.
Si aún así quieres mostrar más agradecimiento puedes realizar una donación en paypal o criptomonedas en el apartado “DONACIONES” que encontrarás en la página de inicio de nuestra web.
