Cuentas y direcciones
En ZooBC tu clave es tu cuenta. Una cuenta nativa se identifica por su clave pública Ed25519, escrita como una dirección de 66 caracteres que empieza por ZBC_. Nadie emite direcciones: una billetera deriva la tuya de tu clave, y puede hacerlo sin conexión. Cada dirección lleva una suma de verificación, así que una copia con una errata se rechaza antes de enviar nada.
Cómo es una dirección
Una dirección nativa es el prefijo ZBC, un guion bajo y 56 caracteres en siete grupos de ocho:
ZBC_57J5D5QV_OPO4JILA_RQW2JC77_OOIDM4VM_BHFCLTKB_2DOFOR4L_Z24K7SFREste ejemplo se generó a partir de un hash para el quiz de zoobc.how. Nadie tiene su clave, así que nunca envíes monedas a ella.
Los 56 caracteres son 35 bytes escritos en base32, un alfabeto formado por las letras mayúsculas de la A a la Z y los dígitos del 2 al 7: los 32 bytes que identifican la cuenta, seguidos de una suma de verificación de 3 bytes.
Los 32 bytes son la clave
Dentro de la cadena una cuenta no es texto. Es un número de tipo de 4 bytes seguido de una carga cuya longitud decide el tipo. El tipo 0 es la cuenta nativa de ZooBC, y su carga es la propia clave pública Ed25519 de la cuenta, no un hash de ella. Por tanto, cualquiera puede leer la clave directamente de la dirección: a partir de la versión 0.5.8 la API del nodo responde a /api/v1/accounts/<address>/pubkey para una cuenta nativa a partir de la dirección sola.
Otras cadenas lo hacen de otra manera, y ZooBC las sigue cuando usa sus direcciones. La carga de una cuenta de Ethereum son los últimos 20 bytes de un hash Keccak-256 de la clave, y la de una cuenta clásica de Bitcoin (P2PKH), el HASH160 de 20 bytes de la clave. ZooBC acepta cuentas de Bitcoin, Ethereum, Solana, Polkadot, Cardano, Ripple, Tron y Tezos, cada una escrita como la escribe su cadena de origen y verificada con el esquema de firma de su cadena de origen (claves y tipos de cuenta).
La suma de verificación detecta erratas
La suma de verificación son los 3 primeros bytes de SHA3-256 sobre la carga de 32 bytes seguida de las tres letras del prefijo. Lo que sea que decodifique una dirección, ya sea la billetera, las herramientas de línea de comandos o la API del nodo, la vuelve a calcular y rechaza la dirección cuando no coincide. Una errata al azar solo produce otra dirección válida aproximadamente una vez cada 2^24 intentos, o 16.7 millones. Como comprobación para el quiz, se probaron los 1736 cambios de un solo carácter de la dirección de ejemplo anterior, y todos fueron rechazados.
El rechazo ocurre antes de construir una transacción, así que no se envía nada. El propio consenso nunca decodifica texto: las transacciones llevan las direcciones como bytes, y la suma de verificación la comprueban las herramientas que convierten texto en bytes. No existe ninguna búsqueda de la «cuenta más parecida», y las monedas enviadas a una dirección equivocada pero válida no volverían por sí solas.
Escribir una dirección
La decodificación sigue una regla de caracteres significativos: se descartan todos los guiones bajos, guiones y espacios en blanco, saltos de línea incluidos, y lo que queda se pasa a mayúsculas. Así, ZBC_57J5D5QV_…, zbc-57j5d5qv-…, una dirección sin ningún separador y una que se partió en dos líneas de un correo electrónico se decodifican todas en los mismos 32 bytes, y después la suma de verificación se comprueba como siempre. Los separadores y las mayúsculas solo existen para ayudar a las personas a leer y copiar.
Prefijos
Las tres letras del prefijo indican para qué sirve una clave:
| Prefijo | Significado |
|---|---|
ZBC_ | una cuenta (tipo 0) |
ZNK_ | una clave de nodo (claves de un nodo) |
ZBR_ | una clave de relay (relays) |
ZBG_ | una clave de pasarela (pasarelas) |
ZBS_ | un objeto de dataset (tipo 10, datasets) |
La API también acepta una forma ZTX_ para los ids de transacción.
Como la suma de verificación cubre el prefijo, los mismos 32 bytes bajo dos prefijos comparten los primeros 51 caracteres tras el prefijo y solo difieren en los cinco últimos. La clave de ejemplo escrita como clave de nodo termina en …_2DOFOR4L_Z24FR5JM en lugar de …_2DOFOR4L_Z24K7SFR. Cambiar el prefijo a mano, sin volver a calcular el final, rompe la suma de verificación, así que la edición se detecta. La cuenta propia de un nodo es la forma ZBC_ de su clave de nodo.
Direcciones sin clave
Algunas direcciones nativas no son claves en absoluto. Ninguna clave privada corresponde a ellas, así que ninguna firma puede gastar desde ellas, y sus monedas solo se mueven según las propias reglas del protocolo:
- los fondos del protocolo: el fondo de longevidad
ZBCLONGV, el fondo de almacenamientoZBCSTOREy el fondo de appsZBCAPPS, cada uno un nombre ASCII rellenado con ceros hasta 32 bytes (fondos); - un grupo de cuentas, nombrado por un hash de la transacción que lo fundó (grupos de cuentas);
- una cuenta multifirma, un hash de su umbral y sus participantes (multifirma);
- un objeto de dataset, el hash de la transacción que lo creó (datasets).
Todo es público
Cada nodo tiene el estado completo, y su API responde a cualquiera, sin cuenta, sin clave y sin clave de API. GET /api/v1/accounts/<address> devuelve el saldo, y las rutas /history, /transactions y /movements que cuelgan de ella listan lo que ha hecho la cuenta y cada cambio de su saldo con su causa, incluidos el alquiler pagado y las recompensas ganadas. Los exploradores muestran los mismos datos como páginas web (explorador y los nodos de archivo).
Lo que la cadena no registra es quién eres. Una dirección es una clave, no un nombre, y nada en la cadena la vincula a una persona a menos que alguien establezca ese vínculo. Por tanto, la privacidad en ZooBC proviene de cómo usas las direcciones, no de saldos ocultos. Hace falta una clave para actuar, nunca para mirar.
Una cuenta que tiene ZBC paga un pequeño alquiler, y una cuenta cuyo saldo no alcanza para pagarlo se poda (alquiler de cuenta y la poda).