Comparte de forma segura la importancia de tu cuenta con un nodo y obtén recompensas.
La cosecha delegada permite que las cuentas recibir recompensas de crear nuevos bloques sin correr un nodo. Al mismo tiempo, permite que los nodos se beneficien de la cuenta (posiblemente mayor) puntaje de importancia.
Note
Los propietarios de los nodos tienen acceso a la configuración del nodo, por lo que es más conveniente para ellos usar Cosecha remota en cambio.
Esta guía explica cómo activar manualmente la cosecha delegada utilizando la interfaz del SDK o la CLI y está dirigida destinado a desarrolladores. Los usuarios deberían utilizar la guía de la Desktop Wallet en su lugar.
Pasos requeridos:
Delega la importancia de la cuenta principal (M) a una cuenta remota (R) utilizando una transacción de enlace de cuenta.
Vincula la cuenta principal M a una cuenta VRF (V) para la producción aleatoria de bloques y la selección de cuentas utilizando una transacción de enlace de clave VRF.
Vincula la cuenta principal M a un nodo para realizar la cosecha a través de ese nodo utilizando una transacción de enlace de clave de nodo.
Solicita al nodo que agregue la cuenta remota R como cosechadora utilizando una transacción de solicitud de delegación persistente. Alternativamente, si se tiene acceso a la configuración del nodo, se puede configurar la clave privada de la cuenta remota en la configuración del nodo.
Ten en cuenta que depende totalmente del nodo cumplir con la solicitud. Algunos nodos pueden proporcionar su lista actual de cosechadores delegados, pero esta información no siempre está disponible (ver Verificando la activación a continuación).
Completa la guía de envío de tokens y mensajes entre dos cuentas para tener una comprensión básica de las transacciones.
Antes de activar la cosecha delegada, necesitas tener los siguientes elementos:
Un Main account (M) con almenos 10,000 bitxor para que eligible y luego un poco más para pagar las tarifas de transacción. La cuenta también tiene que tener un importance score mayor que cero (esta puntuación se calcula cada 12h). Esta es la cuenta que recibirá las tarifas de cosecha. Mantener su clave privada en secreto en todo momento.
Un Remote account (R) que actuará como un proxy entre M y el nodo. Esta cuenta nunca debe haber enviado o recibido ninguna transacción, y no puede participar en ninguna transacción mientras sea una cuenta delegada.
Un VRF account (V) que nunca ha enviado ni recibido ninguna transacción. Es una cuenta regular que se usa para agregar aleatoriedad al proceso de selección de cuentas.
El nodo publico TLS key. Esta es la clave que utiliza el nodo para autenticar los datos para el transporte a través de TLS y normalmente lo proporciona el propietario del nodo.
Note
The following bash code snippets make use of bitxor-cli and assume that the main account (M) is set as the default profile. Use the ‑‑profile parameter if this is not the case.
Crear un AccountKeyLinkTransaction para delegate M’s importance to R. Firma la transacción con M y anúnciala a la red.
const accountLinkTransaction = AccountKeyLinkTransaction.create(
Deadline.create(epochAdjustment),
remoteAccount.publicKey,
LinkAction.Link,
networkType,
UInt64.fromUint(2000000),
);
bitxor-cli transaction accountkeylink \
--linked-public-key <REMOTE_PUBLIC_KEY> \
--action Link \
--sync
Create a VrfKeyLinkTransaction to link M to a VRF key. Sign the transaction with M and announce it to the network.
const vrfLinkTransaction = VrfKeyLinkTransaction.create(
Deadline.create(epochAdjustment),
vrfAccount.publicKey,
LinkAction.Link,
networkType,
UInt64.fromUint(2000000),
); // Absolute number
bitxor-cli transaction vrfkeylink \
--linked-public-key <VRF_PUBLIC_KEY> \
--action Link \
--sync
Crear un NodeKeyLinkTransaction para vincular M a un nodo TLS key. Firme NodeKeyLinkTransaction con M y anúncielo a la red.
Note
La clave TLS pública del nodo generalmente la proporciona el propietario del nodo. Sin embargo, los nodos Dual (siendo ambos Peer y API nodos) ejecutando una versión del REST Gateway más alto que 2.2.0 ofrecer esta información a través del nodePublicKey campo de la node/info REST endpoint.
Simplemente apunte su navegador a NODE_URL /node/info.
const nodeLinkTransaction = NodeKeyLinkTransaction.create(
Deadline.create(epochAdjustment),
nodeAccount.publicKey,
LinkAction.Link,
networkType,
UInt64.fromUint(2000000),
); // Absolute number
bitxor-cli transaction nodekeylink \
--linked-public-key <NODE_PUBLIC_TLS_KEY> \
--action Link \
--sync
Una vez confirmadas las transacciones, el siguiente paso es comparte la clave privada de R con el nodo. Esto se puede hacer de dos maneras dependiendo de si usted es el propietario del nodo y tiene acceso a la configuración del nodo o no.
Si eres el propietario del nodo, simplemente necesita configurar la clave de firma privada de la cuenta remota en el harvesterSigningPrivateKey campo en el Configuración de cosecha.
De lo contrario, un persistentdelegationrequesttransaction debe ser usado. Como la clave privada se compartirá en un mensaje encriptado, solo el nodo podrá verlo. Además, R no posee ningún token.
Las tarifas de recolección se enviarán a M ya que ha establecido un enlace con el nodo a través del NodeKeyLinkTransaction.
Firma el persistentdelegationrequesttransaction con M y anunciarlo en la red.
const persistentDelegationRequestTransaction = PersistentDelegationRequestTransaction.createPersistentDelegationRequestTransaction(
Deadline.create(epochAdjustment),
remoteAccount.privateKey,
vrfAccount.privateKey,
nodeAccount.publicKey,
networkType,
UInt64.fromUint(2000000),
);
# Optionally use --profile announcer
bitxor-cli transaction persistentharvestdelegation \
--remote-private-key <REMOTE_PRIVATE_KEY> \
--recipient-public-key <NODE_PUBLIC_TLS_KEY> \
--vrf-private-key <VRF_PRIVATE_KEY> \
--sync
Note
Todas las transacciones anteriores se pueden anunciar juntas en un solo Transacción Agregada.
Si todo es exitoso, el nodo recibirá el mensaje encriptado a través de WebSockets. Una vez que el nodo descifra la clave privada del posible recolector delegado, el propietario del nodo puede agregar R como recolector delegado si se cumplen los siguientes requisitos:
El nodo permite la recolección delegada.
El nodo tiene espacios de recolección disponibles (ver la siguiente sección).
La cuenta remota nunca ha enviado ni recibido transacciones antes.
Como la clave privada remota se guarda en el disco por el nodo, incluso si el nodo se desconecta temporalmente los recolectores delegados persistentes se restablecerán una vez que el nodo se reconecte a la red.
Además, el uso de un mensaje encriptado crea una copia de seguridad de la información para los nodos. Si el disco que contiene las claves delegadas se corrompe o destruye, el propietario del nodo aún puede recuperar los datos consultando la cadena de bloques.
Al solicitar la delegación a través de un persistentdelegationrequesttransaction en lugar de configurar directamente el nodo, si el nodo habilita la recolección delegada depende completamente del nodo y no de la red. Depende totalmente del nodo cumplir con la solicitud o incluso mentir sobre su estado.
Por lo tanto, no existe una forma confiable de saber si su cuenta se ha convertido en un recolector o no (además de esperar a ver si aparece algún bloque en la cadena de bloques firmado por su cuenta remota y su cuenta principal comienza a cobrar tarifas de recolección).
Dicho esto, nodos configurados para actuar como nodos Dual (siendo ambos Peer y API nodos) se puede consultar su lista actual de recolectores delegados. Para reiterar, esta información proviene del nodo y no está respaldada por la cadena de bloques, así que tómelo con pinzas.
Puede recuperar esta lista utilizando el getUnlockedAccount API endpoint (apunta tu navegador a NODE_URL /node/unlockedaccount) o el Typescript SDK Por ejemplo). Contiene las claves públicas de todos los recolectores delegados registrados en el nodo, por lo que la clave pública de su cuenta remota (R) debería aparecer aquí.
De forma predeterminada, un nodo puede tener hasta 5 recolectores delegados (ranuras de recolección) y las solicitudes en exceso se pueden priorizar según lo considere conveniente el nodo. Esto se puede configurar en el nodo a través del maxUnlockedAccounts y delegatePrioritizationPolicy Configuración de cosecha.
Las cuentas con mayor importancia se seleccionan con mayor frecuencia para realizar la recolección. Incluso si se registra con éxito como recolector delegado con un nodo, no recolectará ningún bloque (ni recibirá ninguna tarifa) a menos que su puntaje de importancia es lo suficientemente alto.
El cálculo de la puntuación de importancia no se realiza continuamente. De forma predeterminada, las puntuaciones de importancia de la cuenta se vuelven a calcular cada 1440 bloques (aproximadamente cada 12 horas). Ver la propiedad importanceGrouping en el Configuring network properties guía.
Finalmente, como se explica en Verificando la activación anterior, anunciar una solicitud de Delegación de Cosecha no garantiza ser agregado como recolector delegado. Los nodos son libres de cumplir con la solicitud o incluso de mentir sobre su estado.
Last updated by John Doe
on 2023‑06‑12.
