Entendiendo los masternodes

Los masternodes, que alguna vez fueron exclusivos de la red Dash, ahora se están haciendo populares a medida que la tecnología se bifurca en otras cadenas de bloques. Esta sección de la documentación describe los principios y mecanismos de los masternodes y los servicios que proporcionan específicamente a la red Dash.

Simply put, a masternode is a server with a full copy of the Dash blockchain, which guarantees a certain minimum level of performance and functionality to perform certain tasks related to block validation, as well as PrivateSend and InstantSend, as the privacy and instant transaction features in Dash are called. The masternodes are paid for this service, using a concept known as Proof of Service. This is in addition to the Proof of Work done by miners to secure the blockchain. Masternodes are also allowed to vote on governance and funding proposals, with each masternode receiving one vote (yes/no/abstain) on each proposal submitted to the system.

Cualquiera puede ejecutar un masternode. El objetivo es tener suficiente descentralización para garantizar que ninguna persona controle una fracción significativa de los masternodes. Sin embargo, para evitar el congestionamiento de la red con masternodes innecesarios o el fomento de operadores imprudentes, hay una condición que debe cumplirse: prueba de propiedad de 1000 Dash. No es necesario que las monedas estén en el masternode, pero deben mantenerse de una manera que sea transparente para toda la red. Si el propietario mueve o gasta esas monedas, el masternode deja de funcionar y el pago cesa.

Masternodes are paid by the network for the PrivateSend, InstantSend and governance services they provide. 45% of the block reward is paid out to the masternodes, 45% to miners and 10% to the budget. In practice, half of the reward from a normal block goes to the miner and half to the masternode. Then, every 16,616 blocks (approximately 30.29 days), a superblock is created that contains the entire 10% payout to the budget proposal winners. Masternodes are selected for payment in each block (approximately every 2.6 minutes) from a deterministic masternode list, and moved to the back of the list after payment. As more masternodes are created, the duration between payments increases. If the collateral behind a masternode is spent, or if a masternode stops providing services to the network for more than one hour, it is removed from the list until normal service resumes. In this way, masternodes are given incentive to provide efficient and reliable services to the network.

Tener tantos servidores con una copia completa de la cadena de bloques y trabajando para la moneda puede ser extremadamente útil. Gracias al sistema de recompensas, no existe el riesgo de no tener suficientes masternodes, y los desarrolladores pueden confiar en que implementarán rápidamente cualquier nueva función descentralizada que se desee implementar. Aquí es donde radica la verdadera fortaleza de Dash - un sistema incentivado de miles de servidores distribuidos que funcionan 24x7 significa que Dash puede escalar más eficientemente y desplegar servicios más rápidamente que una cadena de bloques operada completamente por voluntarios no remunerados. Cuantos más masternodes, mejor y más segura es la red Dash.

As of November 2018, the Dash network has over 5000 masternodes located in over 45 countries and hosted on over 140 ISPs. The block reward is approximately 3.34 Dash, so the selected masternode receives 1.67 Dash per payment or approximately 6 Dash per month. The block reward decreases by 7.14% approximately once per year, so the annual earnings for a masternode owner is approximately 7% of the collateral, and will decrease over time as calculated here. See this tool to calculate real-time payment rates, and this site for various real-time statistics on the masternode network.

DIP003 Masternode Changes

Dash 0.13.0 implements DIP003, which introduces several changes to how a Dash masternode is set up and operated. A list of available documentation appears below:

Important concepts and changes:

  • It is possible to upgrade an existing masternode in-place without starting a new server and without moving your 1000 DASH collateral.
  • A masternode was previously «started» using the masternode start-alias command based on a masternode.conf file. Under DIP003, this file is no longer used, and masternodes are «registered» instead of «started». Masternodes begin offering services when a ProRegTx special transaction containing a particular key is written to the blockchain.
  • As before in masternode.conf, the ProRegTx references the transaction id (txid) and index holding the collateral. The IP address and port of the masternode are also defined in this transaction.
  • The ProRegTx contains 2 Dash addresses (also called public keys) and one BLS public key, which represent 3 different roles in the masternode and define update and voting rights. The keys are:
    1. ownerKeyAddr: This is a Dash address (public key) controlled by the masternode owner. It is different from the address used for the collateral. Because the owner uses the private key associated with this address to issue ProUpRegTx transactions, it must be unique for each masternode.
    2. operatorPubKey: This is the BLS public key of the masternode operator. Only the operator is allowed to issue ProUpServTx transactions. Because the operator key is used during live masternode operation to sign masternode-related P2P messages, quorum-related messages and governance trigger votes, the BLS key must be unique for each masternode.
    3. votingKeyAddr: This is a Dash address (public key) used for proposal voting. Votes signed with the corresponding private key are valid while the masternode is in the registered set.
  • Masternode payments were previously sent to the address holding the collateral. Under DIP003, the owner should specify a different address to receive payments in the ProRegTx. The owner may optionally specify a non-zero percentage as payment to a separate masternode operator, if applicable.
  • The masternode configuration can later be updated using ProUpServTx, ProUpRegTx and ProUpRevTx transactions. See Updating Masternode Information in DIP003 and Actualizando información de Masternode in this documentation for more details.
  • All functions related to DIP003 will only take effect once Spork 15 is enabled on the network. Until then, it is necessary to set up the masternode following the old process and then work through the upgrade procedure. In this state, the masternode will continue to function in compatibility mode, and all DIP003 related functions, such as payments to a separate address or percentage payments to operators, will not yet have any effect. The ownerKeyAddr and votingKeyAddr must also be identical until Spork 15 is enabled.

The process of setting up or upgrading a masternode is as follows:

  1. Set up your server and operating system
  2. Install the Dash software and synchronize the blockchain
  3. Generate a BLS key pair and enter the private key on the masternode
  4. Prepara una transacción de ProRegTx
  5. Firma la transacción ProRegTx
  6. Submit the signed ProRegTx transaction

Step 1 can be omitted if you have an existing server. Steps 2 and 3 require direct access to the masternode. Steps 3 and 4 require access to a Dash Wallet (or DMT). Step 5 requires access to the wallet actually holding the collateral. Step 6 requires a Dash balance to pay the transaction fee.

Masternodes vs. minería

Dash, como Bitcoin y la mayoría de las otras criptomonedas, se basa en un libro contable descentralizado de todas las transacciones, conocido como cadena de bloques. Esta cadena de bloques está asegurada a través de un mecanismo de consenso; en el caso de Dash y Bitcoin, el mecanismo de consenso es Prueba de trabajo (PoW). Mineros intentan resolver problemas difíciles con computadoras especializadas, y cuando resuelven el problema, reciben el derecho de agregar un nuevo bloque a la cadena de bloques. Si todas las demás personas que ejecutan el software están de acuerdo en que el problema se resolvió correctamente, el bloque se agrega a la cadena de bloques y se recompensa al minero.

Sin embargo, Dash funciona de manera diferente a Bitcoin, ya que tiene una red de dos niveles. El segundo nivel es impulsado por los masternodes (nodos completos), que permiten la privacidad financiera (PrivateSend), las transacciones instantáneas (InstantSend) y el sistema de governanza y presupuesto descentralizado. Debido a que este segundo nivel es tan importante, los masternodes también se recompensan cuando los mineros descubren nuevos bloques. El desglose es el siguiente: el 45% de la recompensa por bloque se otorga al minero, el 45% va a los masternodes y el 10% se reserva para el sistema de presupuesto (creado por los superbloques cada mes).

El sistema de masternodes se conoce como Prueba de Servicio (PoSe), ya que los masternodes proporcionan servicios cruciales a la red. De hecho, toda la red es supervisada por los masternodes, que tienen el poder de rechazar bloques formados incorrectamente por los mineros. Si un minero intenta tomar toda la recompensa del bloque por sí mismo o intenta ejecutar una versión anterior del software Dash, la red de masternodes deshabilitaría ese bloque, y no se agregaría a la cadena de bloques.

En resumen, los mineros impulsan el primer nivel, que es el envío y recepción de fondos básicos y la prevención del gasto doble. Los masternodes potencian el segundo nivel, que proporciona las características adicionales que hacen que Dash sea diferente de otras criptomonedas. Los masternodes no minan, y las computadoras de minería no pueden actuar como masternodes. Además, cada masternode está «asegurado» por 1000 DASH. Esos DASH permanecen bajo el control exclusivo de su propietario en todo momento, y se pueden gastar libremente. Los fondos no están bloqueados de ninguna manera. Sin embargo, si los fondos se mueven o gastan, el masternode asociado se desconectará y dejará de recibir recompensas.

Lógica de pagos

Masternode payments in Dash version 0.13.0 are entirely deterministic and based on a simple list sort algorithm. For documentation of version 0.12.0 payment logic, see the legacy masternode payment documentation. Dash version 0.13.0 implements DIP003 and defines two sets of masternodes.

  1. The full set, which contains all registered masternodes that have not spent their collateral funding transactions.
  2. The valid set, a subset of the full set which contains all masternodes which are not marked as Proof of Service (PoSe) banned.

Each masternode in the set of valid masternodes, identified by its registration transaction ID, is associated with the block at which it was last paid. If it has never received payment or was banned for failing to meet the PoSe requirements, then the block at which it was first registered or at which service was restored is used instead. The list is sorted in ascending order by this block height and ProRegTx hash (as a tie breaker in case two masternodes were registered in the same block), and the first entry is selected for payment.

Proof of Service

Proof of Service (PoSe) is a scoring system used to determine if a masternode is providing network services in good faith. A number of metrics are involved in the calculation, so it is not possible to game the system by causing masternodes to be PoSe banned for failing to respond to ping requests by e.g. a DDoS attack just prior to payment. Each failure to provide service results in an increase in the PoSe score relative to the maximum score, which is equal to the number of registered masternodes. If the score reaches the number of registered masternodes, a PoSe ban is enacted and the masternode must be repaired to ensure it provides reliable service and registered in the list again using a ProUpServTx. The current scoring rules as of Dash 0.14 are:

  • Failure to participate in DKG= 66% punishment
  • Each subsequent block reduces PoSe score by 1

Selección de quórum

In past versions of Dash, quorums of 10 masternodes were formed spontaneously to lock InstantSend transactions. As of Dash 0.14, quorums are deterministically formed, contain more masternodes and remain alive for a longer period of time. While they remain responsible for InstantSend transactions, the locking mechanism has changed to automatically attempt locks on most network transactions according to the requirements described here. Masternodes are now also responsible for more network consensus functions, such as ChainLocks. Masternode quorums are formed through a process of distributed key generation. Failure to participate in DKG will eventually result in a PoSe ban as described above.

Requerimientos para los masternodes

  • 1000 Dash: Posiblemente la parte más difícil. Dash se puede obtener en casas de cambio como Poloniex, Bittrex, Kraken y LiveCoin. El servicio de Shapeshift también es una excelente manera.
  • Un servidor o VPS que ejecuta Linux: las guías más recientes usan Ubuntu 18.04 LTS. Recomendamos servicios de VPS como Vultr y DigitalOcean, aunque cualquier proveedor decente lo hará. Por lo general, una instancia con especificaciones por debajo del promedio lo hará, aunque los requisitos de rendimiento aumentarán de acuerdo con esta hoja de ruta.
  • Una dirección IP dedicada: por lo general, vienen con el VPS/servidor.
  • Un poco de tiempo y (corazón): los masternodes solían requerir una configuración compleja, pero herramientas como dashman ahora simplifican enormemente el proceso.

In addition to the 1000 Dash held in collateral, masternodes also have minimum hardware requirements. For Dash versions 0.14 and higher, these requirements are as follows:

  Mínimo Recomendado
CPU 1x 1 GHz 1x 2 GHz
RAM 2 GB + 2 GB swap 4 GB + 2 GB swap
Disco 40 GB 60 GB
Red 400 GB/mth 1 TB/mth

El uso del ancho de banda de los masternodes oscila entre 300-500 GB por mes y crecerá a medida que la red lo haga.

Evolución de Dash

Los requisitos de hardware exactos para los masternodes de Dash Evolution aún no se han determinado, aunque se pueden tomar algunos indicadores del Plan de trabajo y esta publicación de blog. Debería ser posible ejecutar los masternodes de Dash en servidores VPS normales hasta que el tamaño del bloque alcance aproximadamente 20 MB, después de lo cuál se requerirán hardwarse personalizados como GPUs y eventualmente ASICs.