Обзор по интеграции#

Эта документация также доступна в формате PDF.

Dash Core is a fork of Bitcoin Core and shares many common functionalities. Key differences are found in existing JSON-RPC commands which have been customized to support unique functionalities such as InstantSend.

The Basics#

Dash is a Proof of Work network, and similar to Bitcoin, Dash has a mining network but uses a different block hashing algorithm. Dash serves as an improvement of Bitcoin’s shortcomings by offering a robust solution for instant transactions, enhancing user privacy, and offering a self-sustainable decentralized governance model.

JSON-RPC Interface#

The majority of commands are unchanged from Bitcoin making integration into existing systems relatively straightforward. Note that the following commands have been modified to support InstantSend:

Block Hashing Algorithm#

Dash uses the X11 algorithm in place of SHA256 used in Bitcoin. It’s important to note, however, that this only affects the hashing of the block itself. All other internals utilize SHA256 hashes (transactions, merkle root, etc.), which allows for most existing libraries to work in the Dash ecosystem.

Специальные транзакции#

Dash Core v0.13.x introduced the concept of “Special Transactions”. Please see the Transaction Type Integration Guide for more information.

Специальные транзакции#

Эта документация также доступна в формате PDF.

Dash 0.13.0 and higher implement DIP002 Special Transactions, which form a basis for new transaction types that provide on-chain metadata to assist various consensus mechanisms. The following special transaction types exist:

Релиз

Версия

Тип

Размер нагрузки

Нагрузка

Нагрузка JSON

Назначение транзакции

v0.13.0

3

0

n/a

n/a

n/a

Стандартная транзакция

v0.13.0

3

1

<variable int>

<hex>

proRegTx

Masternode Registration

v0.13.0

3

2

<variable int>

<hex>

proUpServTx

Update Masternode Service

v0.13.0

3

3

<variable int>

<hex>

proUpRegTx

Update Masternode Operator

v0.13.0

3

4

<variable int>

<hex>

proUpRevTx

Masternode Revocation

v0.13.0

3

5

<variable int>

<hex>

cbTx

Masternode List Merkle Proof

v0.13.0

3

6

<variable int>

<hex>

qcTx

Quorum Commitment

Примечания по интеграции:

  1. DIP002 Специальные тразакции - основной компонент Dash Core v0.13.0, он вводит новые версии транзакций и соответствующую им «Нагрузку» сети

  2. Integrated Systems must be able to serialize and deserialize these new Transaction Types to accurately encode and decode Raw Transaction data.

  3. С точки зрения обратной совместимости, 4-байтная (32-bit) поле версии, включённое в Старые транзакции, было разделено на два поля: версия и тип (каждое состоит из 2 байтов).

  4. Refer to the Special Transactions section of the dash developer reference for additional detail on these data types, e.g. <variable int>.

  5. InstantSend status and Payload JSON (e.g. proRegTx) is included in the JSON-RPC response, please note that this data is not part of the calculated hash and is provided for convenience.

Чтобы увидеть рабочие примеры каждого типа транзакций, смотрите документацию по интеграции типов транзакций v0.13.0 (PDF) .

InstantSend#

This documentation is also available as a PDF.

InstantSend is a feature provided by the Dash network that allows for zero-confirmation transactions to be safely accepted and re-spent. The network attempts to lock the inputs of every valid transaction when it is broadcast to the network. Every secured transaction is included in a following block in accordance with standard blockchain principles.

InstantSend is enabled by the Masternode Network which comprises approximately 5,000 masternode servers. These nodes are differentiated from standard nodes by having proven ownership of 1,000 Dash, making the network highly resistant to Sybil attacks. Masternodes form Long-Living Masternode Quorums (LLMQs), which are responsible for providing near-instant certainty to the transaction participants that the transaction inputs cannot be respent, and that the transaction will be included in a following block instead of a conflicting transaction.

This concept works as an extension to Nakamoto Consensus. InstantSend enables transacted funds to be immediately and securely respent by the recipient, even before the transaction is included in a block.

Получение транзакций InstantSend#

Вводится два требования для получения транзакций InstantSend:

  1. Возможность определить «статус InstantSend» в заданной транзакции.

  2. Возможность настройки «статуса подтверждения» независимо от подтверждения блока.

InstantSend Status обычно определяется через прямое соединение с демоном dash, уведомление ZMQ, или с помощью сценария уведомления внешнего кошелька.

Прямое соединение: Статус InstantSend может быть идентифицирован через прямое соединение с демоном Dash с использованием протокола JSON-RPC. Атрибут «instantlock» ответа JSON отражает состояние транзакции и включён в следующие команды:

ZMQ Notification: Whenever a transaction enters the mempool and whenever a transaction is locked in the mempool, ZMQ notifications can be broadcast by the node. A list of possible ZMQ notifications can be found here.

The following notifications are relevant for recognizing transactions and their corresponding instantlocks:

  • zmqpubhashtx

  • zmqpubhashtxlock

  • zmqpubrawtx

  • zmqpubrawtxlock

Уведомление кошелька: Dash Core Daemon можно настроить для выполнения внешнего скрипта всякий раз, когда выполняется транзакция InstantSend, связанная с конкретным кошельком. Настройка производится путём добавления следующей строки в файл dash.conf:

instantsendnotify=/path/to/concurrent/safe/handler %s

This is typically used with a wallet that has been populated with watch-only addresses.

Распространение транзакций InstantSend#

Since Dash v0.14.0 established LLMQs on the Dash network, quorums will now attempt to lock every valid transaction by default without any additional fee or action by the sending wallet or user. A transaction is eligible for InstantSend when each of its inputs is considered confirmed. This is the case when at least one of the following circumstances is true:

  • the previous transaction referred to by the input is confirmed with 6 blocks

  • the previous transaction is confirmed through an older InstantSend lock

  • the block containing the previous transaction is ChainLocked

When checking the previous transaction for an InstantSend lock, it is important to do this on mempool (non-mined) transactions. This allows chained InstantSend locking.

Дополнительные ресурсы#

Следующие ресурсы предоставляют дополнительную информацию о функции InstantSend и предназначены для обеспечения более полного понимания базовых технологий.