t0dd
Active member
I'm working on a DashForceNews article that discusses scale from a user/merchant perspective. Capacity, throughput, latency, response times... throughout the phases of an interaction between a payer and a payee...
The stated transaction "speed" of Dash is approximately 48 transactions per second. This is a raw "included in a block" metric with loads of variables at play and ignores a lot of other factors involved in a transaction and the perception to a customer and merchant.
What I am curious about is InstantSend. How does it fare when pushed to scale? Do we have some ideas surrounding this?
The unique thing about InstantSend (IS) is that it combines the world of blockchain (a discrete synchronous transaction heartbeat) with the world of traditional client-server (client-cloud?): "as fast as you can move data"; continuous; asynchronous. Scaling IS is more similar to traditional scaling any other network. You have anticipated load... the ability to form a quorum of 10 masternodes, and the ability to send and receive data with the client.
So, the first 5 confirmation equivalents are asynchronous and operate at masternode-network-speed. But it is that last 6 confirmation post-lock-in that then requires the transaction to settle to the blockchain. Off-chain then on-chain.
But the transaction is locked. At least amongst the masternodes. But what if the network is flooded? Blocks are filled, people are queuing up IS payments that are waiting to be included in a block. Those payments still are guaranteed...
But is there a breaking point? I know there is a 15 second timeout, but that really only addresses response time between client and server. Not a filled pipeline of unconfirmed IS transactions.
Anyone have thoughts on this? The article is not going to be utterly low level, but I want to make sure I am characterizing things appropriately. Plus this is a really interesting topic.
Thanks! -t0dd (in discord, keybase as toddwarner, etc. etc.)
...
PS. For those interested in reading about some of the mechanics of all this, we have outstanding documentation:
The stated transaction "speed" of Dash is approximately 48 transactions per second. This is a raw "included in a block" metric with loads of variables at play and ignores a lot of other factors involved in a transaction and the perception to a customer and merchant.
What I am curious about is InstantSend. How does it fare when pushed to scale? Do we have some ideas surrounding this?
The unique thing about InstantSend (IS) is that it combines the world of blockchain (a discrete synchronous transaction heartbeat) with the world of traditional client-server (client-cloud?): "as fast as you can move data"; continuous; asynchronous. Scaling IS is more similar to traditional scaling any other network. You have anticipated load... the ability to form a quorum of 10 masternodes, and the ability to send and receive data with the client.
So, the first 5 confirmation equivalents are asynchronous and operate at masternode-network-speed. But it is that last 6 confirmation post-lock-in that then requires the transaction to settle to the blockchain. Off-chain then on-chain.
But the transaction is locked. At least amongst the masternodes. But what if the network is flooded? Blocks are filled, people are queuing up IS payments that are waiting to be included in a block. Those payments still are guaranteed...
But is there a breaking point? I know there is a 15 second timeout, but that really only addresses response time between client and server. Not a filled pipeline of unconfirmed IS transactions.
Anyone have thoughts on this? The article is not going to be utterly low level, but I want to make sure I am characterizing things appropriately. Plus this is a really interesting topic.
Thanks! -t0dd (in discord, keybase as toddwarner, etc. etc.)
...
PS. For those interested in reading about some of the mechanics of all this, we have outstanding documentation:
Last edited: