Neenooo
21.2k Publicaciones
Neenooo
Verificado Plus de Binance SquareUnwanted
867 Siguiendo
64.8K+ Seguidores
56.4K+ Me gusta
Publicaciones
Todo
Citas
Videos
Live
PINNED
PINNED
Parcialmente cierto
Pasé un tiempo pensando en lo que significa “descentralizado” cuando la participación sigue estando filtrada.
Newton describe a sus operadores como “permissioned” para la calidad y la rendición de cuentas, pero descentralizados en términos de neutralidad y resiliencia. El conjunto de operadores no es “permissionless”. Los operadores deben cumplir requisitos operativos que incluyen disponibilidad, tiempo de respuesta y distribución geográfica, además de requisitos de cumplimiento que implican el estatus de entidad legal y la jurisdicción. Newton lo llama un “conjunto de operadores descentralizado verificablemente” (“credibly vetted”).
Al principio, parecía que @NewtonProtocol estaba renunciando a algo de apertura.
Pero con el tiempo, la elección pareció más práctica. Los sistemas “permissionless” permiten una participación más amplia, pero no aportan automáticamente un rendimiento sólido ni una rendición de cuentas clara. El modelo de Newton, en cambio, busca distribuir la operación entre entidades independientes, proveedores de infraestructura, regiones geográficas y jurisdicciones legales, mientras aún aplica requisitos de entrada.
Ahí está la fortaleza.
Newton también utiliza un cuórum BLS ponderado por participación y configurable. Su documentación explica que, con un umbral de cuórum del 67% y sin que ningún operador controle más del 33% de la participación total, al menos tres entidades de operadores independientes deben estar de acuerdo antes de que una atestación sea válida.
Pero esa condición importa.
Una lista distribuida de operadores no responde por sí sola a todas las preguntas sobre la descentralización. La resiliencia todavía depende de si la participación y el control operativo permanecen suficientemente distribuidos entre entidades genuinamente independientes.
El diseño publicado de descentralización explica los requisitos del operador y el modelo de cuórum, pero no describe el proceso de admisión de operadores con el nivel de detalle suficiente para definir quién aprueba a los nuevos participantes ni cómo se protege la neutralidad en ese límite.
La parte que no he resuelto es si la participación “permissioned” crea una descentralización verificablemente (“credibly vetted”), o si reemplaza el acceso abierto por una federación gestionada.
¿El modelo de operadores verificados de Newton fortalece la descentralización?
#Newt $NFP $M
#NEWT
$NEWT
Newton describe a sus operadores como “permissioned” para la calidad y la rendición de cuentas, pero descentralizados en términos de neutralidad y resiliencia. El conjunto de operadores no es “permissionless”. Los operadores deben cumplir requisitos operativos que incluyen disponibilidad, tiempo de respuesta y distribución geográfica, además de requisitos de cumplimiento que implican el estatus de entidad legal y la jurisdicción. Newton lo llama un “conjunto de operadores descentralizado verificablemente” (“credibly vetted”).
Al principio, parecía que @NewtonProtocol estaba renunciando a algo de apertura.
Pero con el tiempo, la elección pareció más práctica. Los sistemas “permissionless” permiten una participación más amplia, pero no aportan automáticamente un rendimiento sólido ni una rendición de cuentas clara. El modelo de Newton, en cambio, busca distribuir la operación entre entidades independientes, proveedores de infraestructura, regiones geográficas y jurisdicciones legales, mientras aún aplica requisitos de entrada.
Ahí está la fortaleza.
Newton también utiliza un cuórum BLS ponderado por participación y configurable. Su documentación explica que, con un umbral de cuórum del 67% y sin que ningún operador controle más del 33% de la participación total, al menos tres entidades de operadores independientes deben estar de acuerdo antes de que una atestación sea válida.
Pero esa condición importa.
Una lista distribuida de operadores no responde por sí sola a todas las preguntas sobre la descentralización. La resiliencia todavía depende de si la participación y el control operativo permanecen suficientemente distribuidos entre entidades genuinamente independientes.
El diseño publicado de descentralización explica los requisitos del operador y el modelo de cuórum, pero no describe el proceso de admisión de operadores con el nivel de detalle suficiente para definir quién aprueba a los nuevos participantes ni cómo se protege la neutralidad en ese límite.
La parte que no he resuelto es si la participación “permissioned” crea una descentralización verificablemente (“credibly vetted”), o si reemplaza el acceso abierto por una federación gestionada.
¿El modelo de operadores verificados de Newton fortalece la descentralización?
#Newt $NFP $M
#NEWT
$NEWT
🔘 Yes—quality and resilience
🔘 No—admission limits neutral
🔘 Both—depends on distributio
🔘 Too early to judge
12 hora(s) restante(s)
#newt $NEWT @NewtonProtocol #NEWT
Inicialmente pensé que una política era solo una regla fija que se carga una vez y se sigue para siempre.
Newton separa la lógica de políticas reutilizables de Rego de la configuración asociada a un PolicyClient. Su propietario puede proporcionar parámetros como umbrales, límites de exposición o listas de direcciones aprobadas, y la Gateway pasa esa configuración JSON plana dentro de la política como data.params.
Eso cambia el diseño.
La lógica subyacente puede permanecer igual mientras cambia su límite de aplicación. Una aplicación puede configurar un límite más alto. Otra puede aplicar la misma regla con uno más estricto.
Una configuración de PolicyClient también incluye expireAfter, pero esto no hace que caduquen o se actualicen los parámetros en sí. Determina la ventana de bloqueo durante la cual aún se puede ejecutar una atestación. Si se establece demasiado corto, los usuarios pueden no tener tiempo suficiente para completar la transacción. Si se establece demasiado largo, la aprobación permanece utilizable durante una ventana de seguridad más amplia.
Lo que destacó no fue la flexibilidad por sí sola.
Fue el lugar donde se mueve la responsabilidad.
La política puede ser pública y determinista, pero el resultado práctico aún depende de quién selecciona los parámetros, cómo se revisan esos valores y cuánto tiempo siguen siendo ejecutables las aprobaciones creadas bajo esa configuración.
Actualizar los parámetros del PolicyClient llama setPolicy(PolicyConfig) de nuevo y devuelve un nuevo policyId. La documentación de Newton indica que el policy ID registrado previamente queda obsoleto, mientras que la validación requiere que el policy ID de la atestación coincida con la configuración actual del cliente.
Eso crea un límite visible de configuración, pero los usuarios aún necesitan entender qué cambió detrás del nuevo identificador.
La parte que aún no he terminado de resolver es si los PolicyClients configurables hacen que una regla sea reutilizable de forma segura, o si colocan un juicio importante dentro de ajustes que la mayoría de los usuarios no inspeccionará.
¿La aplicación parametrizada crea controles adaptables o hace que, de todos modos, la misma lógica de política lleve supuestos de confianza muy diferentes?
¿Los PolicyClients configurables mejoran la aplicación o esconden demasiado juicio en la configuración?
$SYN $H
Inicialmente pensé que una política era solo una regla fija que se carga una vez y se sigue para siempre.
Newton separa la lógica de políticas reutilizables de Rego de la configuración asociada a un PolicyClient. Su propietario puede proporcionar parámetros como umbrales, límites de exposición o listas de direcciones aprobadas, y la Gateway pasa esa configuración JSON plana dentro de la política como data.params.
Eso cambia el diseño.
La lógica subyacente puede permanecer igual mientras cambia su límite de aplicación. Una aplicación puede configurar un límite más alto. Otra puede aplicar la misma regla con uno más estricto.
Una configuración de PolicyClient también incluye expireAfter, pero esto no hace que caduquen o se actualicen los parámetros en sí. Determina la ventana de bloqueo durante la cual aún se puede ejecutar una atestación. Si se establece demasiado corto, los usuarios pueden no tener tiempo suficiente para completar la transacción. Si se establece demasiado largo, la aprobación permanece utilizable durante una ventana de seguridad más amplia.
Lo que destacó no fue la flexibilidad por sí sola.
Fue el lugar donde se mueve la responsabilidad.
La política puede ser pública y determinista, pero el resultado práctico aún depende de quién selecciona los parámetros, cómo se revisan esos valores y cuánto tiempo siguen siendo ejecutables las aprobaciones creadas bajo esa configuración.
Actualizar los parámetros del PolicyClient llama setPolicy(PolicyConfig) de nuevo y devuelve un nuevo policyId. La documentación de Newton indica que el policy ID registrado previamente queda obsoleto, mientras que la validación requiere que el policy ID de la atestación coincida con la configuración actual del cliente.
Eso crea un límite visible de configuración, pero los usuarios aún necesitan entender qué cambió detrás del nuevo identificador.
La parte que aún no he terminado de resolver es si los PolicyClients configurables hacen que una regla sea reutilizable de forma segura, o si colocan un juicio importante dentro de ajustes que la mayoría de los usuarios no inspeccionará.
¿La aplicación parametrizada crea controles adaptables o hace que, de todos modos, la misma lógica de política lleve supuestos de confianza muy diferentes?
¿Los PolicyClients configurables mejoran la aplicación o esconden demasiado juicio en la configuración?
$SYN $H
🔘 Adaptable, safer controls
66%
🔘 Same logic, different trust
34%
29 Voto(s) • Votación cerrada
Pasé un tiempo pensando en lo que significa la soberanía cuando la infraestructura de IA se comparte.
OpenGradient describe el Neuro Stack como una pila de desarrollo modular y de código abierto para crear appchains habilitadas para IA y redes de Capa 2 (L2). Estas redes pueden desarrollar infraestructura especializada y precompilados mientras utilizan la arquitectura HACA de OpenGradient, nodos de inferencia, datos y almacenamiento, Model Hub, SDK y red de liquidación.
Al principio, la idea pareció ideal.
Los desarrolladores pueden crear una blockchain especializada mientras usan las herramientas existentes de OpenGradient para modelos, cómputo y verificación.
Pero la soberanía se vuelve más complicada cuando permanecen compartidos los componentes fundamentales más importantes.
Dependiendo de su diseño, una cadena de Neuro Stack puede controlar su lógica de aplicación, reglas, infraestructura especializada e incluso potencialmente su propio token o espacio de bloques, mientras sigue dependiendo de OPG para partes de su inferencia, herramientas de modelos, datos, almacenamiento y ruta de liquidación.
Eso no hace que la cadena sea carente de sentido o no soberana.
Significa que la soberanía puede existir en las capas de aplicación y gobernanza, mientras que las dependencias operativas permanecen en otro lugar de la pila.
Esa es la parte a la que sigo volviendo.
Los componentes fundamentales compartidos pueden reducir el costo de crear redes de IA especializadas y permitir que las herramientas desarrolladas para una cadena de Neuro Stack se reutilicen en otras. Pero diferentes cadenas aún pueden construirse alrededor de esos componentes usando reglas distintas, precompilados y supuestos de aplicación.
Por lo tanto, una mayor personalización podría ampliar la experimentación, pero también hacer que los estándares, las herramientas y las expectativas de los usuarios sean menos consistentes.
@OpenGradient current documentation todavía describe varias cadenas de Neuro Stack como desarrolladas con clientes en alfa privada. También dice que aún se están desarrollando primitivas más amplias de interoperabilidad y coordinación, así que el lanzamiento no debería presentarse como una red pública de appchains ya madura.
¿La infraestructura compartida hace que las appchains de IA soberanas sean prácticas, o crea redes especializadas cuya independencia permanece estrechamente ligada a la misma pila subyacente?
#OPG $OPG $SYN $BTW
OpenGradient describe el Neuro Stack como una pila de desarrollo modular y de código abierto para crear appchains habilitadas para IA y redes de Capa 2 (L2). Estas redes pueden desarrollar infraestructura especializada y precompilados mientras utilizan la arquitectura HACA de OpenGradient, nodos de inferencia, datos y almacenamiento, Model Hub, SDK y red de liquidación.
Al principio, la idea pareció ideal.
Los desarrolladores pueden crear una blockchain especializada mientras usan las herramientas existentes de OpenGradient para modelos, cómputo y verificación.
Pero la soberanía se vuelve más complicada cuando permanecen compartidos los componentes fundamentales más importantes.
Dependiendo de su diseño, una cadena de Neuro Stack puede controlar su lógica de aplicación, reglas, infraestructura especializada e incluso potencialmente su propio token o espacio de bloques, mientras sigue dependiendo de OPG para partes de su inferencia, herramientas de modelos, datos, almacenamiento y ruta de liquidación.
Eso no hace que la cadena sea carente de sentido o no soberana.
Significa que la soberanía puede existir en las capas de aplicación y gobernanza, mientras que las dependencias operativas permanecen en otro lugar de la pila.
Esa es la parte a la que sigo volviendo.
Los componentes fundamentales compartidos pueden reducir el costo de crear redes de IA especializadas y permitir que las herramientas desarrolladas para una cadena de Neuro Stack se reutilicen en otras. Pero diferentes cadenas aún pueden construirse alrededor de esos componentes usando reglas distintas, precompilados y supuestos de aplicación.
Por lo tanto, una mayor personalización podría ampliar la experimentación, pero también hacer que los estándares, las herramientas y las expectativas de los usuarios sean menos consistentes.
@OpenGradient current documentation todavía describe varias cadenas de Neuro Stack como desarrolladas con clientes en alfa privada. También dice que aún se están desarrollando primitivas más amplias de interoperabilidad y coordinación, así que el lanzamiento no debería presentarse como una red pública de appchains ya madura.
¿La infraestructura compartida hace que las appchains de IA soberanas sean prácticas, o crea redes especializadas cuya independencia permanece estrechamente ligada a la misma pila subyacente?
#OPG $OPG $SYN $BTW
🔹 Yes — specialization matter
100%
🔹 No — dependencies limit sov
0%
2 Voto(s) • Votación cerrada
HACA separa la ejecución de la verificación. Los nodos de inferencia especializados gestionan las solicitudes de IA, mientras que los nodos completos verifican la evidencia y mantienen el libro mayor
$RAVE $TAC
$RAVE $TAC
Beboo_
·
--
$TAC $GWEI $OPG
HACA separa la ejecución de GPU de la verificación respaldada por TEE
Antes pensaba que la IA descentralizada se enfrentaba a un problema de hardware sencillo.
Encontrar suficientes GPUs, distribuir la carga de trabajo y el resto eventualmente se resolvería. Pero la ejecución “en bruto” empezó a parecer menos valiosa cuando noté lo poco que puede demostrar una máquina potente sobre su respuesta. Una GPU puede producir un resultado rápidamente. No puede establecer que el proceso aprobado haya gestionado la solicitud ni que la respuesta se haya mantenido sin cambios.
Esa distinción es lo que hace interesante para mí la arquitectura HACA de OpenGradient.
HACA separa la ejecución de la verificación. Nodos de inferencia especializados gestionan las solicitudes de IA, mientras que los nodos completos verifican la evidencia y mantienen el libro mayor. Los validadores no repiten cada inferencia costosa, y los usuarios pueden recibir respuestas mientras la liquidación de la prueba continúa de forma asíncrona.
Cuando se utiliza la verificación con TEE, la atestación proporciona evidencia respaldada por el hardware de que el código de enclave aprobado gestionó el flujo solicitud-respuesta sin modificaciones no autorizadas. Los nodos completos comprueban que esa evidencia coincida con la información registrada del enclave antes de que el consenso la acepte.
Esa forma de expresarlo importa. La atestación de un TEE no necesariamente prueba que cada cómputo de GPU ocurrió dentro del enclave, especialmente cuando un proxy de LLM enruta una solicitud protegida hacia un proveedor de modelos externo. Verifica el límite de ejecución confiable y la integridad del proceso que se está atestiguando.
Por lo tanto, el producto valioso no es solo la capacidad de GPUs. Es la separación entre realizar el trabajo de IA y establecer si la evidencia que lo acompaña debe considerarse confiable.
Aun así, la verificación no es inteligencia. No puede demostrar que un modelo sea preciso, imparcial, útil o interpretado de forma responsable.
Como trader, estoy observando si HACA mantiene baja latencia a medida que crece el volumen de pruebas, si los desarrolladores pagan por una verificación más sólida y si la inferencia verificada crea una demanda recurrente.
Las GPUs pueden hacer que la IA sea más rápida. La pregunta más profunda es si HACA puede hacer que esa velocidad sea responsable
@OpenGradient #OPG
HACA separa la ejecución de GPU de la verificación respaldada por TEE
Antes pensaba que la IA descentralizada se enfrentaba a un problema de hardware sencillo.
Encontrar suficientes GPUs, distribuir la carga de trabajo y el resto eventualmente se resolvería. Pero la ejecución “en bruto” empezó a parecer menos valiosa cuando noté lo poco que puede demostrar una máquina potente sobre su respuesta. Una GPU puede producir un resultado rápidamente. No puede establecer que el proceso aprobado haya gestionado la solicitud ni que la respuesta se haya mantenido sin cambios.
Esa distinción es lo que hace interesante para mí la arquitectura HACA de OpenGradient.
HACA separa la ejecución de la verificación. Nodos de inferencia especializados gestionan las solicitudes de IA, mientras que los nodos completos verifican la evidencia y mantienen el libro mayor. Los validadores no repiten cada inferencia costosa, y los usuarios pueden recibir respuestas mientras la liquidación de la prueba continúa de forma asíncrona.
Cuando se utiliza la verificación con TEE, la atestación proporciona evidencia respaldada por el hardware de que el código de enclave aprobado gestionó el flujo solicitud-respuesta sin modificaciones no autorizadas. Los nodos completos comprueban que esa evidencia coincida con la información registrada del enclave antes de que el consenso la acepte.
Esa forma de expresarlo importa. La atestación de un TEE no necesariamente prueba que cada cómputo de GPU ocurrió dentro del enclave, especialmente cuando un proxy de LLM enruta una solicitud protegida hacia un proveedor de modelos externo. Verifica el límite de ejecución confiable y la integridad del proceso que se está atestiguando.
Por lo tanto, el producto valioso no es solo la capacidad de GPUs. Es la separación entre realizar el trabajo de IA y establecer si la evidencia que lo acompaña debe considerarse confiable.
Aun así, la verificación no es inteligencia. No puede demostrar que un modelo sea preciso, imparcial, útil o interpretado de forma responsable.
Como trader, estoy observando si HACA mantiene baja latencia a medida que crece el volumen de pruebas, si los desarrolladores pagan por una verificación más sólida y si la inferencia verificada crea una demanda recurrente.
Las GPUs pueden hacer que la IA sea más rápida. La pregunta más profunda es si HACA puede hacer que esa velocidad sea responsable
@OpenGradient #OPG
Pasé un tiempo pensando en lo que significa que la gobernanza de tokens llegue hasta el hardware.
OpenGradient dice que la gobernanza puede votar sobre el hardware TEE compatible, la fijación de precios del gas, la asignación de tesorería y las actualizaciones del protocolo.
Al principio, eso sonaba a una participación amplia.
Es más técnico que eso.
Elegir hardware TEE compatible no solo implica aprobar una lista de proveedores. Puede influir en qué entornos de confianza de hardware acepta la red para inferencias verificables.
Por separado, el código de enclave aprobado se verifica frente a hashes de PCR mantenidos mediante un proceso de aprobación en cadena.
La fijación de precios del gas marca el costo de usar la red repetidamente. Las decisiones sobre la tesorería influyen en qué iniciativas de investigación, infraestructura y ecosistema reciben apoyo.
Eso es mucha arquitectura oculta dentro de una sola etiqueta de gobernanza.
La fortaleza potencial es clara. Las partes interesadas reciben un rol formal en decisiones que podrían dar forma a la infraestructura de la red, en lugar de dejar cada opción importante fijada de manera permanente por sus desarrolladores originales.
Pero los derechos de voto no hacen automáticamente que las decisiones técnicas sean comprensibles.
Es posible que la mayoría de los votantes no entienda por completo los riesgos del hardware, las decisiones sobre precios, el gasto de tesorería o las actualizaciones del protocolo. Es posible que dependan de expertos para explicar qué significa realmente cada propuesta.
Eso crea otro punto de concentración: no necesariamente el control sobre los votos, sino el control sobre cómo se explican las decisiones técnicas.
Lo que no puedo resolver es si la gobernanza técnica realmente distribuye el control o si principalmente distribuye la responsabilidad de decisiones que la mayoría de los votantes no pueden verificar personalmente.
¿Votar sobre la infraestructura hace que OpenGradient sea más responsable, o decisiones de ingeniería profundamente especializadas podrían convertirse en concursos de popularidad con consecuencias a nivel de todo el protocolo?
¿La gobernanza técnica realmente distribuye el control?
$RAVE $GWEI
#OPG @OpenGradient t $OPG
OpenGradient dice que la gobernanza puede votar sobre el hardware TEE compatible, la fijación de precios del gas, la asignación de tesorería y las actualizaciones del protocolo.
Al principio, eso sonaba a una participación amplia.
Es más técnico que eso.
Elegir hardware TEE compatible no solo implica aprobar una lista de proveedores. Puede influir en qué entornos de confianza de hardware acepta la red para inferencias verificables.
Por separado, el código de enclave aprobado se verifica frente a hashes de PCR mantenidos mediante un proceso de aprobación en cadena.
La fijación de precios del gas marca el costo de usar la red repetidamente. Las decisiones sobre la tesorería influyen en qué iniciativas de investigación, infraestructura y ecosistema reciben apoyo.
Eso es mucha arquitectura oculta dentro de una sola etiqueta de gobernanza.
La fortaleza potencial es clara. Las partes interesadas reciben un rol formal en decisiones que podrían dar forma a la infraestructura de la red, en lugar de dejar cada opción importante fijada de manera permanente por sus desarrolladores originales.
Pero los derechos de voto no hacen automáticamente que las decisiones técnicas sean comprensibles.
Es posible que la mayoría de los votantes no entienda por completo los riesgos del hardware, las decisiones sobre precios, el gasto de tesorería o las actualizaciones del protocolo. Es posible que dependan de expertos para explicar qué significa realmente cada propuesta.
Eso crea otro punto de concentración: no necesariamente el control sobre los votos, sino el control sobre cómo se explican las decisiones técnicas.
Lo que no puedo resolver es si la gobernanza técnica realmente distribuye el control o si principalmente distribuye la responsabilidad de decisiones que la mayoría de los votantes no pueden verificar personalmente.
¿Votar sobre la infraestructura hace que OpenGradient sea más responsable, o decisiones de ingeniería profundamente especializadas podrían convertirse en concursos de popularidad con consecuencias a nivel de todo el protocolo?
¿La gobernanza técnica realmente distribuye el control?
$RAVE $GWEI
#OPG @OpenGradient t $OPG
🔘 Yes, it improves accountab
75%
🔘 No, experts still shape dec
13%
🔘 It depends on voter partici
0%
🔘 Too early to judge
12%
16 Voto(s) • Votación cerrada
Pasé un tiempo pensando en en qué parte realmente comienza una decisión de un modelo.
SolidML incluye una precompilación de preprocesamiento de datos que los contratos inteligentes pueden llamar al preparar información para la inferencia. Admite operaciones como media, varianza, desviación estándar, mediana, normalización, estandarización y correlación on-chain.
Al principio, eso sonó como apoyar las matemáticas.
No lo es.
Un modelo a menudo espera que sus entradas tengan un formato particular. OpenGradient dice que la precompilación permite que los contratos inteligentes transformen o agreguen datos a ese formato esperado, realizando en la cadena las operaciones intensivas de cómputo.
Pero la ejecución correcta no garantiza una preparación adecuada.
Los mismos datos pueden prepararse de varias maneras. La matemática puede estar bien, pero la entrada final aun así puede darle al modelo una imagen deficiente del problema real.
Esa es la distinción que sigo notando.
La ejecución en cadena puede hacer que el cálculo de preprocesamiento solicitado sea verificable. No puede determinar si el desarrollador eligió la transformación, variables, conjunto de datos o ventana de observación correctos antes de pasar el resultado al modelo.
SolidML y la inferencia de ML en cadena están disponibles actualmente solo en la red de pruebas alfa descontinuada de OpenGradient, no en su red principal de pruebas. La inferencia de ML en cadena sigue en desarrollo para la red principal de pruebas.
Esa frontera experimental importa más que la aritmética.
¿El preprocesamiento verificable fortalece la inferencia en cadena, o traslada decisiones subjetivas de datos a código que parece objetivo porque sus cálculos pueden comprobarse?
¿El preprocesamiento verificable hace que la IA en cadena sea más confiable?
#OPG @OpenGradient $OPG $ACT $VELVET
SolidML incluye una precompilación de preprocesamiento de datos que los contratos inteligentes pueden llamar al preparar información para la inferencia. Admite operaciones como media, varianza, desviación estándar, mediana, normalización, estandarización y correlación on-chain.
Al principio, eso sonó como apoyar las matemáticas.
No lo es.
Un modelo a menudo espera que sus entradas tengan un formato particular. OpenGradient dice que la precompilación permite que los contratos inteligentes transformen o agreguen datos a ese formato esperado, realizando en la cadena las operaciones intensivas de cómputo.
Pero la ejecución correcta no garantiza una preparación adecuada.
Los mismos datos pueden prepararse de varias maneras. La matemática puede estar bien, pero la entrada final aun así puede darle al modelo una imagen deficiente del problema real.
Esa es la distinción que sigo notando.
La ejecución en cadena puede hacer que el cálculo de preprocesamiento solicitado sea verificable. No puede determinar si el desarrollador eligió la transformación, variables, conjunto de datos o ventana de observación correctos antes de pasar el resultado al modelo.
SolidML y la inferencia de ML en cadena están disponibles actualmente solo en la red de pruebas alfa descontinuada de OpenGradient, no en su red principal de pruebas. La inferencia de ML en cadena sigue en desarrollo para la red principal de pruebas.
Esa frontera experimental importa más que la aritmética.
¿El preprocesamiento verificable fortalece la inferencia en cadena, o traslada decisiones subjetivas de datos a código que parece objetivo porque sus cálculos pueden comprobarse?
¿El preprocesamiento verificable hace que la IA en cadena sea más confiable?
#OPG @OpenGradient $OPG $ACT $VELVET
🔘 Yes, it strengthens inferen
61%
🔘 Only if inputs are well cho
11%
🔘 It verifies math, not judgm
17%
🔘 Still too experimental
11%
18 Voto(s) • Votación cerrada
En un principio pensé que una inferencia verificada se volvería portable en el momento en que su prueba quedara resuelta.
El diseño modular de la cadena de OpenGradient apunta a algo más amplio. Su documentación dice que IBC podría habilitar en el futuro la inferencia de IA entre cadenas. También indica que los usuarios individuales y los clientes ligeros pueden verificar inferencias específicas ya resueltas, lo que permite a usuarios fuera de cadena y entre cadenas ganar confianza en sus resultados.
Eso suena poderoso.
Pero transportar una salida no necesariamente es lo mismo que transportar todo lo que otra aplicación necesita para evaluarla.
Una aplicación de destino puede necesitar más que un número o una respuesta generada. También puede necesitar información sobre el modelo, los compromisos de entrada y salida, la prueba o atestación, el registro de liquidación, los metadatos de la inferencia y el método de verificación que respalda el resultado.
Para la inferencia de LLM, la cantidad de datos registrados en la cadena ya varía según el modo de liquidación.
“PRIVATE” usa la liquidación individual sin publicar en cadena los hashes de la entrada ni de la salida, manteniendo los datos de la inferencia fuera de la cadena.
“BATCH_HASHED” agrega múltiples inferencias en una sola liquidación mediante un árbol de Merkle que contiene los hashes de entrada y salida y las firmas.
“INDIVIDUAL_FULL” registra información completa del modelo, los datos completos de entrada y salida, y todos los metadatos de la inferencia en la cadena.
Ahí es donde sigo notando el límite.
La interoperabilidad podría hacer que la inteligencia verificada sea reutilizable en lugar de aislada. Pero una aplicación de destino aún necesitaría reglas claras para determinar qué evidencia acompañó al resultado, cómo debería verificarse esa evidencia y qué conclusiones respalda realmente.
De lo contrario, una inferencia completamente documentada en OpenGradient podría convertirse en un mensaje entre cadenas que lleve solo una parte de su contexto original de verificación.
Como la inferencia entre cadenas habilitada por IBC todavía se describe como una funcionalidad futura, el formato de mensaje eventual, la disponibilidad de la evidencia y las reglas de verificación del lado del destino importarán.
¿La inferencia de IA entre cadenas puede preservar el contexto de confianza que hay detrás de una salida verificada?
$VELVET $SLX
#OPG @OpenGradient $OPG
El diseño modular de la cadena de OpenGradient apunta a algo más amplio. Su documentación dice que IBC podría habilitar en el futuro la inferencia de IA entre cadenas. También indica que los usuarios individuales y los clientes ligeros pueden verificar inferencias específicas ya resueltas, lo que permite a usuarios fuera de cadena y entre cadenas ganar confianza en sus resultados.
Eso suena poderoso.
Pero transportar una salida no necesariamente es lo mismo que transportar todo lo que otra aplicación necesita para evaluarla.
Una aplicación de destino puede necesitar más que un número o una respuesta generada. También puede necesitar información sobre el modelo, los compromisos de entrada y salida, la prueba o atestación, el registro de liquidación, los metadatos de la inferencia y el método de verificación que respalda el resultado.
Para la inferencia de LLM, la cantidad de datos registrados en la cadena ya varía según el modo de liquidación.
“PRIVATE” usa la liquidación individual sin publicar en cadena los hashes de la entrada ni de la salida, manteniendo los datos de la inferencia fuera de la cadena.
“BATCH_HASHED” agrega múltiples inferencias en una sola liquidación mediante un árbol de Merkle que contiene los hashes de entrada y salida y las firmas.
“INDIVIDUAL_FULL” registra información completa del modelo, los datos completos de entrada y salida, y todos los metadatos de la inferencia en la cadena.
Ahí es donde sigo notando el límite.
La interoperabilidad podría hacer que la inteligencia verificada sea reutilizable en lugar de aislada. Pero una aplicación de destino aún necesitaría reglas claras para determinar qué evidencia acompañó al resultado, cómo debería verificarse esa evidencia y qué conclusiones respalda realmente.
De lo contrario, una inferencia completamente documentada en OpenGradient podría convertirse en un mensaje entre cadenas que lleve solo una parte de su contexto original de verificación.
Como la inferencia entre cadenas habilitada por IBC todavía se describe como una funcionalidad futura, el formato de mensaje eventual, la disponibilidad de la evidencia y las reglas de verificación del lado del destino importarán.
¿La inferencia de IA entre cadenas puede preservar el contexto de confianza que hay detrás de una salida verificada?
$VELVET $SLX
#OPG @OpenGradient $OPG
🔹 Yes, if the evidence trave
57%
🔹 Only with strict standards
7%
🔹 The output alone is enough
14%
🔹 Too early to know
22%
14 Voto(s) • Votación cerrada
La presión está aumentando bajo la resistencia mientras los compradores sostienen la tendencia ⚡
$SLX
ENTRADA: 0.462 – 0.468
OBJETIVOS: 0.483 – 0.495 – 0.515
STOP LOSS: 0.451
$SLX permanece por encima de cada EMA principal, mientras que el MACD positivo respalda la continuación alcista. El RSI cerca de 70 muestra que el impulso es fuerte, pero ligeramente estirado.
Mantener 0.462 mantiene a los compradores bajo control. Un rompimiento limpio por encima de 0.483 podría activar la próxima expansión.
Haz la operación Aquí en $SLX 👇
$SLX
ENTRADA: 0.462 – 0.468
OBJETIVOS: 0.483 – 0.495 – 0.515
STOP LOSS: 0.451
$SLX permanece por encima de cada EMA principal, mientras que el MACD positivo respalda la continuación alcista. El RSI cerca de 70 muestra que el impulso es fuerte, pero ligeramente estirado.
Mantener 0.462 mantiene a los compradores bajo control. Un rompimiento limpio por encima de 0.483 podría activar la próxima expansión.
Haz la operación Aquí en $SLX 👇
La tendencia sigue siendo fuerte, pero el precio está probando el máximo de 24h ⚡
$SYRUP
ENTRADA: 0.1500 – 0.1520
OBJETIVOS: 0.1540 – 0.1580 – 0.1620
STOP LOSS: 0.1470
$SYRUP se mantiene por encima de cada EMA importante, mientras que el RSI cerca de 65 y el MACD positivo respaldan la continuación alcista. Mantener 0.1500 mantiene a los compradores bajo control; una ruptura limpia por encima de 0.1540 podría activar la próxima expansión.
Haz la operación aquí en $SYRUP 👇
$SYRUP
ENTRADA: 0.1500 – 0.1520
OBJETIVOS: 0.1540 – 0.1580 – 0.1620
STOP LOSS: 0.1470
$SYRUP se mantiene por encima de cada EMA importante, mientras que el RSI cerca de 65 y el MACD positivo respaldan la continuación alcista. Mantener 0.1500 mantiene a los compradores bajo control; una ruptura limpia por encima de 0.1540 podría activar la próxima expansión.
Haz la operación aquí en $SYRUP 👇
El impulso sigue siendo poderoso, pero el movimiento de 15m está fuertemente extendido cerca de la resistencia ⚡
$VELVET
ENTRADA: 1.36 – 1.40
OBJETIVOS: 1.476 – 1.55 – 1.65
STOP LOSS: 1.30
$VELVET permanece por encima de cada EMA importante, mientras que el MACD positivo respalda la continuación. El RSI cerca de 74 advierte que no es recomendable perseguir al precio actual.
Mantener 1.36 mantiene intacta la estructura alcista. Una ruptura limpia por encima de 1.476 podría activar la próxima expansión.
Opera aquí en $VELVET 👇
$VELVET
ENTRADA: 1.36 – 1.40
OBJETIVOS: 1.476 – 1.55 – 1.65
STOP LOSS: 1.30
$VELVET permanece por encima de cada EMA importante, mientras que el MACD positivo respalda la continuación. El RSI cerca de 74 advierte que no es recomendable perseguir al precio actual.
Mantener 1.36 mantiene intacta la estructura alcista. Una ruptura limpia por encima de 1.476 podría activar la próxima expansión.
Opera aquí en $VELVET 👇
Al principio pensé que eliminar un nodo comprometido resolvía el problema de la confianza
@OpenGradient utiliza dos rutas diferentes de rendición de cuentas.
Los validadores aseguran el consenso mediante prueba de participación, con conductas maliciosas sujetas a slashing. Los nodos de inferencia operan a través de un registro en cadena: los nodos completos aceptan resultados firmados por nodos registrados, mientras que los nodos comprometidos pueden eliminarse de ese registro.
Al principio, esa separación parecía limpia.
Lo es.
Los operadores del consenso ponen en riesgo capital económico. Los operadores de inferencia se arriesgan a perder la autorización de la red que hace que sus firmas sean aceptables.
Pero la revocación cambia principalmente lo que ocurre después.
Después de que un nodo se elimina, los nuevos resultados firmados por él ya no deberían cumplir el requisito de que el firmante esté registrado. La pregunta más difícil es cómo deberían tratar las aplicaciones las salidas producidas antes de que se descubriera el compromiso.
Sus pruebas quizá ya hayan sido verificadas y registradas de forma permanente mientras el nodo aún estaba autorizado. OpenGradient documenta la finalización instantánea para las pruebas asentadas, pero no describe la revocación posterior como algo que invalide automáticamente o que vuelva a evaluar las salidas históricas de un nodo.
Esa es la parte que no puedo resolver.
El registro puede informarle a la red qué nodos están autorizados ahora. Por sí solo, no puede determinar si cada salida anterior debe conservar el mismo nivel de confianza cuando surgen nuevas evidencias.
La distinción importa porque a menudo el compromiso se descubre después de la actividad, no antes.
El slashing y la revocación pueden proteger la red hacia adelante, mientras que las aplicaciones todavía necesitan políticas para gestionar las salidas que fueron aceptadas antes de que se retirara la confianza.
Cuando se revoca un nodo de inferencia, ¿qué debería pasar con sus salidas aceptadas anteriores?
#OPG @OpenGradient $OPG $MAGMA $AGLD
@OpenGradient utiliza dos rutas diferentes de rendición de cuentas.
Los validadores aseguran el consenso mediante prueba de participación, con conductas maliciosas sujetas a slashing. Los nodos de inferencia operan a través de un registro en cadena: los nodos completos aceptan resultados firmados por nodos registrados, mientras que los nodos comprometidos pueden eliminarse de ese registro.
Al principio, esa separación parecía limpia.
Lo es.
Los operadores del consenso ponen en riesgo capital económico. Los operadores de inferencia se arriesgan a perder la autorización de la red que hace que sus firmas sean aceptables.
Pero la revocación cambia principalmente lo que ocurre después.
Después de que un nodo se elimina, los nuevos resultados firmados por él ya no deberían cumplir el requisito de que el firmante esté registrado. La pregunta más difícil es cómo deberían tratar las aplicaciones las salidas producidas antes de que se descubriera el compromiso.
Sus pruebas quizá ya hayan sido verificadas y registradas de forma permanente mientras el nodo aún estaba autorizado. OpenGradient documenta la finalización instantánea para las pruebas asentadas, pero no describe la revocación posterior como algo que invalide automáticamente o que vuelva a evaluar las salidas históricas de un nodo.
Esa es la parte que no puedo resolver.
El registro puede informarle a la red qué nodos están autorizados ahora. Por sí solo, no puede determinar si cada salida anterior debe conservar el mismo nivel de confianza cuando surgen nuevas evidencias.
La distinción importa porque a menudo el compromiso se descubre después de la actividad, no antes.
El slashing y la revocación pueden proteger la red hacia adelante, mientras que las aplicaciones todavía necesitan políticas para gestionar las salidas que fueron aceptadas antes de que se retirara la confianza.
Cuando se revoca un nodo de inferencia, ¿qué debería pasar con sus salidas aceptadas anteriores?
#OPG @OpenGradient $OPG $MAGMA $AGLD
🔹 Keep them valid
89%
🔹 Reassess them
0%
🔹 Depends on the evidence
0%
🔹 Applications must decide
11%
9 Voto(s) • Votación cerrada
🚨 Los futuros se están calentando rápido!
$MAGMA +66%
$ICNT +47%
$AGLD +44%
Las grandes velas verdes crean oportunidades, pero perseguir tarde puede convertir ganancias en liquidaciones.
¿Qué harás cuando los ganadores se disparen así?
$MAGMA +66%
$ICNT +47%
$AGLD +44%
Las grandes velas verdes crean oportunidades, pero perseguir tarde puede convertir ganancias en liquidaciones.
¿Qué harás cuando los ganadores se disparen así?
🔘 Buy the breakout
32%
🔘 Wait for a pullback
21%
🔘 Look for a short
42%
🔘 Stay out and watch
5%
19 Voto(s) • Votación cerrada
El impulso es explosivo, pero el RSI cerca de 76 hace que perseguir el pico sea arriesgado ⚡
$VELVET
ENTRADA: 0.590 – 0.605
OBJETIVOS: 0.623 – 0.6565 – 0.680
STOP LOSS: 0.578
$VELVET está operando bien por encima de cada EMA principal, mientras que un MACD fuertemente positivo y el aumento del volumen confirman el impulso alcista. Un retest controlado ofrece la configuración más segura.
Mantener 0.590 mantiene intacta la estructura de ruptura; una ruptura limpia por encima de 0.6565 podría activar otra expansión.
Operar Aquí En $VELVET 👇
$VELVET
ENTRADA: 0.590 – 0.605
OBJETIVOS: 0.623 – 0.6565 – 0.680
STOP LOSS: 0.578
$VELVET está operando bien por encima de cada EMA principal, mientras que un MACD fuertemente positivo y el aumento del volumen confirman el impulso alcista. Un retest controlado ofrece la configuración más segura.
Mantener 0.590 mantiene intacta la estructura de ruptura; una ruptura limpia por encima de 0.6565 podría activar otra expansión.
Operar Aquí En $VELVET 👇
La tendencia alcista se mantiene fuerte mientras el precio consolida por debajo de la resistencia ⚡
$ICNT
ENTRADA: 0.2380 – 0.2425
OBJETIVOS: 0.2518 – 0.2600 – 0.2720
STOP LOSS: 0.2330
$ICNT se mantiene por encima de cada EMA importante, mientras que el RSI cerca de 57 y el MACD ligeramente positivo respaldan la continuación alcista. Mantener 0.2380 mantiene a los compradores bajo control; una ruptura limpia por encima de 0.2518 podría activar la siguiente expansión.
Trade Here On $ICNT 👇
$ICNT
ENTRADA: 0.2380 – 0.2425
OBJETIVOS: 0.2518 – 0.2600 – 0.2720
STOP LOSS: 0.2330
$ICNT se mantiene por encima de cada EMA importante, mientras que el RSI cerca de 57 y el MACD ligeramente positivo respaldan la continuación alcista. Mantener 0.2380 mantiene a los compradores bajo control; una ruptura limpia por encima de 0.2518 podría activar la siguiente expansión.
Trade Here On $ICNT 👇
El momentum es explosivo, pero el RSI por encima de 86 hace que perseguir la parte alta sea peligroso ⚡
$MAGMA
ENTRADA: 0.630 – 0.642
OBJETIVOS: 0.679 – 0.700 – 0.730
STOP LOSS: 0.612
$MAGMA está operando muy por encima de todas las EMA principales, mientras que el MACD positivo y el volumen en aumento confirman un fuerte impulso alcista. Sin embargo, el movimiento está fuertemente sobreextendido.
Un retroceso controlado hacia la EMA5 ofrece una configuración más segura. Mantener 0.630 conserva la estructura de ruptura, mientras que al superar 0.679 podría desencadenarse otra expansión.
Operar Aquí En $MAGMA 👇
$MAGMA
ENTRADA: 0.630 – 0.642
OBJETIVOS: 0.679 – 0.700 – 0.730
STOP LOSS: 0.612
$MAGMA está operando muy por encima de todas las EMA principales, mientras que el MACD positivo y el volumen en aumento confirman un fuerte impulso alcista. Sin embargo, el movimiento está fuertemente sobreextendido.
Un retroceso controlado hacia la EMA5 ofrece una configuración más segura. Mantener 0.630 conserva la estructura de ruptura, mientras que al superar 0.679 podría desencadenarse otra expansión.
Operar Aquí En $MAGMA 👇
OpenGradient dice que los modelos se pueden almacenar en caché localmente. La distinción más importante es que los nodos de inferencia no se describen como manteniendo el estado continuo de una conversación o del flujo de trabajo de una aplicación.$MAGMA $HEI $ICNT
Beboo_
·
--
Pasé un tiempo pensando en qué es exactamente lo que recuerda un nodo de inferencia sin estado.
OpenGradient describe los nodos de inferencia como trabajadores sin estado. Dependiendo del tipo de nodo, ejecutan modelos localmente o proporcionan acceso seguro a proveedores de modelos externos. Los resultados se devuelven directamente a los usuarios, mientras que las pruebas y atestaciones se verifican y resuelven de forma asíncrona por los nodos completos.
Al principio, lo “sin estado” sonaba como una limitación.
Puede ser una de las decisiones de diseño más limpias.
Un trabajador no necesita convertirse en el hogar permanente del estado de una aplicación. Las solicitudes pueden distribuirse entre la infraestructura sin hacer que la aplicación en general dependa por completo del historial de sesión local de un solo nodo.
Pero la falta de estado no significa que la máquina no almacene nada. OpenGradient dice que los modelos pueden almacenarse en caché localmente. La distinción más importante es que los nodos de inferencia no se describen como encargados de mantener el estado continuo de conversación o de flujo de trabajo de una aplicación.
Una secuencia de llamadas de IA puede sentirse continua para el usuario, pero la aplicación aún tiene que preservar el contexto relevante, conectar los pasos y asociar cada resultado con la decisión que lo utilizó.
Esa es la parte que no puedo ignorar.
La red puede verificar y rastrear ejecuciones individuales sin demostrar que la aplicación proporcionó suficiente contexto o que combinó los resultados de manera coherente. La integridad de la ejecución no crea automáticamente coherencia del flujo de trabajo.
¿Los nodos de inferencia sin estado mejoran la resiliencia, o trasladan demasiada responsabilidad a la orquestación de la aplicación?
#OPG @OpenGradient $OPG $AGLD $VELVET
OpenGradient describe los nodos de inferencia como trabajadores sin estado. Dependiendo del tipo de nodo, ejecutan modelos localmente o proporcionan acceso seguro a proveedores de modelos externos. Los resultados se devuelven directamente a los usuarios, mientras que las pruebas y atestaciones se verifican y resuelven de forma asíncrona por los nodos completos.
Al principio, lo “sin estado” sonaba como una limitación.
Puede ser una de las decisiones de diseño más limpias.
Un trabajador no necesita convertirse en el hogar permanente del estado de una aplicación. Las solicitudes pueden distribuirse entre la infraestructura sin hacer que la aplicación en general dependa por completo del historial de sesión local de un solo nodo.
Pero la falta de estado no significa que la máquina no almacene nada. OpenGradient dice que los modelos pueden almacenarse en caché localmente. La distinción más importante es que los nodos de inferencia no se describen como encargados de mantener el estado continuo de conversación o de flujo de trabajo de una aplicación.
Una secuencia de llamadas de IA puede sentirse continua para el usuario, pero la aplicación aún tiene que preservar el contexto relevante, conectar los pasos y asociar cada resultado con la decisión que lo utilizó.
Esa es la parte que no puedo ignorar.
La red puede verificar y rastrear ejecuciones individuales sin demostrar que la aplicación proporcionó suficiente contexto o que combinó los resultados de manera coherente. La integridad de la ejecución no crea automáticamente coherencia del flujo de trabajo.
¿Los nodos de inferencia sin estado mejoran la resiliencia, o trasladan demasiada responsabilidad a la orquestación de la aplicación?
#OPG @OpenGradient $OPG $AGLD $VELVET
El descenso brusco fue recuperado, pero aún falta confirmar el impulso ⚡
$SNDK
ENTRADA: 2,175 – 2,205
OBJETIVOS: 2,245 – 2,292 – 2,350
STOP LOSS: 2,135
$SNDK se mantiene por encima de todas las principales EMAs, mientras que el RSI cerca de 58 respalda la recuperación. El MACD sigue en negativo, así que se necesita una ruptura limpia por encima de 2,245 para una continuación más fuerte.
Operar Aquí En $SNDK 👇
$SNDK
ENTRADA: 2,175 – 2,205
OBJETIVOS: 2,245 – 2,292 – 2,350
STOP LOSS: 2,135
$SNDK se mantiene por encima de todas las principales EMAs, mientras que el RSI cerca de 58 respalda la recuperación. El MACD sigue en negativo, así que se necesita una ruptura limpia por encima de 2,245 para una continuación más fuerte.
Operar Aquí En $SNDK 👇
SNDKUS-11,66%
Inicia sesión para explorar más contenidos