Proposal for consensus-enforced atomic swaps between NXT, ARDOR and all clones

This topic contains 0 replies, has 1 voice, and was last updated by  TheWireMaster 1 week, 4 days ago.

  • Author
  • #14741

    This is a proposal from the Ardor/NXT slack by user “tre”:

    Proposal for consensus-enforced atomic swaps between NXT, ARDOR and all clones. Implemented with two new transaction types and logic to verify signed sendMoney transactions from the other platforms and introduced simultaneously on all participating clones.
    The motivation is to allow trust-less, consensus-enforced, simultaneous (locked step) trading of the tokens between accounts on the different platforms. The tokens do not, of course, actually leave the platforms but they are exchanged between the trader’s accounts in such a way that the transfer of tokens on the one platform is also the key to enabling the opposing trade transfer transaction to occur on the other.

    The implementation is in three parts and requires two new phased transactions that must have an equivalent implementation on each platform.
    1. Reserve-Balance. A new phased transaction type. This transaction guarantees that the balance is available to complete the trade.
    This transaction is similar to the sendMoney transaction except that nothing is transferred and that the amountNQT is only locked until a specified block height. This balanced is unreserved in one of two cases: If a sendMoney transaction with otherwise identical fields (amountNQT recipient senderPublicKey) is attempted then this reserved value is used to complete the attempted sendMoney transaction. OR by a transaction (2) that is unlocked.

    2. Template-Lock. A new phased transaction type. This transaction is unlocked by a signed sendMoney transaction from the opposing platform which is being traded with.
    This transaction is also similar to a sendMoney transaction but contains an attachment with a valid unsigned sendMoney transaction that is valid on the opposing platform which is being traded with. The amountNQT field corresponds with the native token to be exchanged and the attachment’s amountNQT field corresponds with opposing platform’s token that is being traded for the native token.
    This transaction is unlocked by (3). The idea will be illustrated with an example below.

    3. Each platform must understand how to verify ordinary signed sendMoney transactionBytes of each other. So NXT should understand ARDOR’s and vice versa. (2) is unlocked when the sending account of (2) receives a message with a binary attachment that corresponds with the signed attachment in (2) and that is valid on the opposing platform i.e. that is a signed sendMoney transactionBytes. The reserved balance of (1) is used to complete the transaction of (2).
    The choice to use a message trigger to unlock (2) has the disadvantage of requiring that the verifying nodes compute messages while the phasing in (2) is active. Perhaps a purpose-specific new transaction would be more efficient. Or perhaps a new message attachment indicator (to compliment messageIsText) type that indicates that it is a trigger for type transaction (2).

    Example of a trade between NXT and IGNIS.

    Alice wants to trade 150 NXT for 100 IGNIS. Bob accepts the trade. Alice and Bob exchange the publickeys that they control on each other’s platform i.e. Bob creates a NXT account and gives their publickey to Alice and Alice does the same for their IGNIS account.
    Alice creates a phased transaction (1) that contains amountNQT 150 NXT and Bob’s recipient account-ID and commits the transaction on the NXT blockchain.
    Bob makes a similar phased transaction (1) that contains amountNQT 100 IGNIS and Alice’s recipient account-ID and commits the transaction on the ARDOR blockchain.
    Alice has locked 150 NXT from their account for a certain number of blocks and Bob has locked 100 IGNIS for a comparable number of blocks.
    Alice confirms that Bob’s transaction (1) has been committed on the blockchain and maybe waits for a number of confirmations. Bob does the same and confirms that Alice’s transaction (1) has been committed. They are both reassured that they each will have the required tokens to complete the trade.
    To continue the trade either Alice or Bob can create a transaction (2) with the agreed parameters for the trade amountNQT. It is not necessary that both create the opposing transaction. Only one is necessary to guarantee the trade. Let us say that Alice creates a transaction (2) with a template for an ARDOR platform IGNIS sendMoney transaction for amountNQT 100 IGNIS and Alice’s recipient and Bob’s senderPublicKey (and appropriate feeNQT ecBlockId ecBlockHeight …).
    To continue the trade Bob can unlock Alice’s phased NXT transaction (2) by sending the correct signed transactionBytes as a NXT message using Alice’s senderPublicKey from transaction (2) This same transactionBytes sent to Alive from Bob can be committed by Alice to the ARDOR blockchain to also unlock Bob’s transaction (1)’s reserved balance and complete the trade.
    The trade has a consensus guarantee once either Alice or Bob create a valid transaction (2). It is up to both parties to take into consideration the phased block height and deadline limits committed by transactions (1) and (2).
    If neither Alice nor Bob continues the trade by supplying (2) then the locked values (1) will be returned to their respective accounts at the specified block height limit.
    The exchange can be automated with an application that is connected to each platform and matches offers off-chain and creates the phased transactions (1) and (2) for each trader and waits for and sends the unlock (3) for the opposing platform.

You must be logged in to reply to this topic.

©2019 Ardor Rocks


Log in with your credentials


Forgot your details?


Create Account