I think if we had two phases of block creation where new transactions are queued for the next block while the hallmark servers achieve consensus on the previously queued transactions and then broadcast to all the non-hallmarked nodes, then 10 seconds is very achievable.
And once again - James goes of into "fantasy land" where real things like "network latency" don't exist.
You were told the reasons - if you just want to ignore them that's fine - but you can't change facts with statements.
Traditional transaction processors generate 1 record per account transaction and confirm it.
Existing card/ATM networks cheat because they do 'authorise' and then confirm/clear the transaction later, and they can only do this because they can reverse and everyone is identifiable.. This model has always been flawed and what is being suggested sounds like it.
The above sounds like its going in that direction by segmenting network/node functions and creating special nodes, this will end up like the above I suspect and flawed.
This is a hard problem - if it was easy to solve the bank networks would not be like they are, they were built when latency was a much bigger problem than it is today, and while its much less of a problem, I agree with CIYAM we ignore it at our peril.
Existing transaction processing systems create a transaction or a block on demand for a single transaction when it arrives, the record is linked to the account and in most systems the TPS limit (H/W not withstanding) it based the time to confirm the transaction (checks, business rules etc) by a single Transaction processor and the account (which is normally locked for the duration of a live transaction) but other than that the systems are inherently asynchronous and process as many transactions in parallel are there are processors.
There are millions of mobiles in Africa sending transactions, via GSM SMS + VPN back to servers in Europe, at over 300tps with confirmation times of less than 10s and these transactions are fully authorised and cleared, and this number is going to grow and the systems exist to service it.
In NXT as I understand it we have a record that is going to be formed whether there are transactions are not, and a single transaction processor - the node that has been chosen to forge.
At 100 tps, with one block every minute that means 6000 records in a block - or have I got that wrong?
So this node needs to confirm all the transactions in the block and then broadcast the results to the rest.
So we have all these nodes available to do work but only one of them at anyone time processes the transactions.
And all those transactions need to go to the right node irrespective of the latency from the client to the forging node.
Depends what your market is,
if you never want to get into the physical retail environment - this is not an issue and you can drop it it can be handled in client software, the website takes your payment, completes the purchase and later you get final confirmation or a rejection - just like any other credit card and bitcoin!
If you want it used in shops, then when you are standing at a till, with a queue of people behind you, there needs to be a guaranteed transaction performance - this is hard and this is why the card companies technically cheat and have built the business model to ensure other people carry the liability e.g. retailer / customer.
Solving this is a combination of node, network and the ability to marshall the work, get it to the right place in the network in advance of execution and then execute it in a guaranteed timeframe - when you know the best timeframe you can achieve then communities like retail will look at it and decide whether its ok, do you need to be sub-second - no, can you take minutes - no.
I can see the issue but I cannot tell you the answer - if I knew the answer I would be building it
perhaps between us we will find it.
