Ayer solicité permisos de API para un proyecto, llené el formulario, esperé tres días y me respondieron por correo que la revisión no fue aprobada, sin darme razones. Fue como esperar en vano.
Este tipo de aprobación en caja negra es demasiado común en Web2; no sabes dónde se traba el proceso y si quieres hacer cambios, no tienes dirección.
El ModelFactory de OpenLedger ha implementado un flujo de aprobación en cadena para el acceso a conjuntos de datos. Si quieres ajustar un modelo con datos de algún Datanet, primero debes hacer un staking de $OPEN para iniciar la solicitud. El proveedor de datos recibe la solicitud y vota para decidir si te otorga o no el acceso. Los resultados de la votación y las razones se registran en la cadena. Si te rechazan, también puedes ver quién votó en contra y por qué.
Revisé el whitepaper y usan un mecanismo de firma múltiple; no es solo un único proveedor de datos quien decide. Un conjunto de datos puede tener múltiples contribuyentes, y cada uno tiene derechos de voto según su peso de contribución. Para acceder a los datos, necesitas obtener más de un umbral de votos a favor. Este diseño evita abusos de poder por parte de los proveedores de datos, por ejemplo, si no les caes bien, no pueden simplemente rechazar tu solicitud.
Además, si te rechazan, el staking de $OPEN se te devuelve íntegro; no se deduce nada. Solo si obtienes los datos y los usas de manera indebida y un verificador lo descubre, se te puede confiscar el staking. Este diseño es bastante razonable, ya que distingue entre 'solicitud fallida' y 'uso indebido', a diferencia de algunos proyectos que solo por fallar te quitan dinero, lo que es una trampa para los usuarios.
Comparé el proceso de aprobación de datos de otras plataformas de IA y la mayoría sigue dependiendo de administradores centralizados que deciden. No tienes ni siquiera un canal de apelación. Las primeras piscinas de minería de Bitcoin también eran centralizadas, pero luego fueron reemplazadas gradualmente por piscinas P2P, ya que todos se dieron cuenta de que la concentración de poder genera corrupción. La implementación de contratos inteligentes de Ethereum también pasó de revisiones centralizadas a validaciones descentralizadas. Este sistema de votación y aprobación en cadena de OpenLedger, en esencia, está replicando el mismo camino, solo que el escenario ha cambiado a control de acceso a conjuntos de datos.
Sin embargo, también noté un problema: los grandes proveedores de datos con mucho peso de voto, si se unen para resistir a un solicitante, teóricamente pueden bloquearlo de forma permanente. El whitepaper no menciona medidas específicas para prevenir conspiraciones, así que esa brecha necesita ser cerrada.
Esperaré a que implementen algunos casos reales de aprobación antes de evaluar si este mecanismo es justo @OpenLedger #OpenLedger .
Este tipo de aprobación en caja negra es demasiado común en Web2; no sabes dónde se traba el proceso y si quieres hacer cambios, no tienes dirección.
El ModelFactory de OpenLedger ha implementado un flujo de aprobación en cadena para el acceso a conjuntos de datos. Si quieres ajustar un modelo con datos de algún Datanet, primero debes hacer un staking de $OPEN para iniciar la solicitud. El proveedor de datos recibe la solicitud y vota para decidir si te otorga o no el acceso. Los resultados de la votación y las razones se registran en la cadena. Si te rechazan, también puedes ver quién votó en contra y por qué.
Revisé el whitepaper y usan un mecanismo de firma múltiple; no es solo un único proveedor de datos quien decide. Un conjunto de datos puede tener múltiples contribuyentes, y cada uno tiene derechos de voto según su peso de contribución. Para acceder a los datos, necesitas obtener más de un umbral de votos a favor. Este diseño evita abusos de poder por parte de los proveedores de datos, por ejemplo, si no les caes bien, no pueden simplemente rechazar tu solicitud.
Además, si te rechazan, el staking de $OPEN se te devuelve íntegro; no se deduce nada. Solo si obtienes los datos y los usas de manera indebida y un verificador lo descubre, se te puede confiscar el staking. Este diseño es bastante razonable, ya que distingue entre 'solicitud fallida' y 'uso indebido', a diferencia de algunos proyectos que solo por fallar te quitan dinero, lo que es una trampa para los usuarios.
Comparé el proceso de aprobación de datos de otras plataformas de IA y la mayoría sigue dependiendo de administradores centralizados que deciden. No tienes ni siquiera un canal de apelación. Las primeras piscinas de minería de Bitcoin también eran centralizadas, pero luego fueron reemplazadas gradualmente por piscinas P2P, ya que todos se dieron cuenta de que la concentración de poder genera corrupción. La implementación de contratos inteligentes de Ethereum también pasó de revisiones centralizadas a validaciones descentralizadas. Este sistema de votación y aprobación en cadena de OpenLedger, en esencia, está replicando el mismo camino, solo que el escenario ha cambiado a control de acceso a conjuntos de datos.
Sin embargo, también noté un problema: los grandes proveedores de datos con mucho peso de voto, si se unen para resistir a un solicitante, teóricamente pueden bloquearlo de forma permanente. El whitepaper no menciona medidas específicas para prevenir conspiraciones, así que esa brecha necesita ser cerrada.
Esperaré a que implementen algunos casos reales de aprobación antes de evaluar si este mecanismo es justo @OpenLedger #OpenLedger .
