Cómo funciona
Una sesión tiene cuatro pasos: descubrimiento, handshake, inferencia y liquidación. Nada del camino lo opera GenKaKu Labs.
1. Descubrimiento
Un worker se registra en WorkerRegistry con:
- un peer ID: la identidad libp2p con la que responderá,
- un policy hash: el modelo y las reglas que ofrece,
- un localizador opcional, como una multiaddr.
El registro expone count() e isActive(address). La app los lee por un RPC público; no hay una API
de directorio en la que confiar.
Los localizadores son opcionales. La app no publica tu IP pública salvo que actives
publishAddress de forma explícita, y un localizador publicado es permanente una vez en la cadena.
2. Handshake
La app abre una conexión libp2p al peer ID del worker. El recorrido de NAT usa DCUtR y, cuando ambos lados están detrás de NAT simétrico, un relay solo para el handshake. Los relays no llevan tráfico de modelo: un presupuesto de 128 KiB / 2 min no sostiene un stream de LLM.
El intercambio hello fija:
- el peer ID (debe coincidir con el registro),
- la dirección de la billetera del worker,
- el policy hash,
- la tarifa por hora y el modo de facturación.
3. Inferencia
El worker ejecuta el modelo localmente con Ollama y transmite tokens por la conexión directa. El mercado no almacena prompts; el operador del worker puede ver el tráfico que sirve.
4. Liquidación
La facturación usa tarifa por hora con acumulación por minuto iniciado:
- el worker anuncia un precio por hora,
- cada minuto iniciado cuenta como un minuto,
- un trabajo de dos minutos paga dos minutos, no una hora.
El usuario abre una sesión en JobEscrow con una cantidad de USDC de prueba. Al terminar:
- el worker firma un recibo con el ID de sesión, el gasto y un hash del recibo;
settle()verifica esa firma y libera el gasto;- el 99% va al worker y el 1% a la tesorería;
- el resto vuelve al usuario con
refund().
El worker puede llamar a claim() cuando quiera para retirar su saldo acumulado.
Qué reemplaza al orquestador
| Modelo anterior | GenKaKu |
|---|---|
| El servidor asigna trabajos | El usuario elige un worker del contrato |
| El servidor guarda prompts | Conexión directa entre pares |
| El servidor mide el uso | Acumulación por minuto y recibo firmado |
| El servidor paga | Escrow liberado en la cadena |
Hay menos supuestos de confianza porque hay menos en medio, pero no son cero: sigues confiando el prompt al worker y sigues confiando en el código que ejecutas.