The rate of increase in transactions could rise very quickly, since already we have posts, votes, power downs, power ups, conversions, flags, and escrow and savings and sbd and there will be sooner or later new types of transactions related to new applications like PEVO and busy and talk of q&a and wikipedia type sites with different kinds of article posts... So I am pleased to hear this is on the agenda for when the transaction flood comes...
I don't know all of the technical points or terms, Loki, but I'm wondering if Dash is using something like the "intermediaries" you describe to provide their "instant" confirmations for transactions? Imo, the real bottleneck for practical spending of bitcoin - for store purchases and whatever - is the long wait for confirmations. So then, intermediaries could provide a quick preconfirmation for spending transactions as well, is this correct?
I'm thinking at some point it would be good if Steem could become "digital cash" like Dash, especially considering all of the types of apps and web properties that can and will eventually be hooked into Steem.
I am more of a mind now that they are mainly caches and replicators for clients, and with the associativity graph and then the split data caches of blocks can replicate network segments (which is smaller) and Intermediaries. Also, it may be better to split up the network more, sooner, far ahead of transaction demand, since this also could shorten the network heartbeat (time to block). This would also allow a minor hardfork to adapt to increasing utilisation (changing the number of parts you divide the network into) instead of letting that be fully automatic.
If current load was handled by 3 blocks at a cycle, it could also process transactions in one second. The paralel blocks could run on staggered seconds, meaning 1 block per second. There also has to be an overlap of accounts between schedule lines, and a simple scheme to independently determine which witness should take the transaction where each schedule thread overlaps.
I will be thinking a lot about this schene yet. scalability and low latency at the same time is the goal.
The rate of increase in transactions could rise very quickly, since already we have posts, votes, power downs, power ups, conversions, flags, and escrow and savings and sbd and there will be sooner or later new types of transactions related to new applications like PEVO and busy and talk of q&a and wikipedia type sites with different kinds of article posts... So I am pleased to hear this is on the agenda for when the transaction flood comes...
I don't know all of the technical points or terms, Loki, but I'm wondering if Dash is using something like the "intermediaries" you describe to provide their "instant" confirmations for transactions? Imo, the real bottleneck for practical spending of bitcoin - for store purchases and whatever - is the long wait for confirmations. So then, intermediaries could provide a quick preconfirmation for spending transactions as well, is this correct?
I'm thinking at some point it would be good if Steem could become "digital cash" like Dash, especially considering all of the types of apps and web properties that can and will eventually be hooked into Steem.
I am more of a mind now that they are mainly caches and replicators for clients, and with the associativity graph and then the split data caches of blocks can replicate network segments (which is smaller) and Intermediaries. Also, it may be better to split up the network more, sooner, far ahead of transaction demand, since this also could shorten the network heartbeat (time to block). This would also allow a minor hardfork to adapt to increasing utilisation (changing the number of parts you divide the network into) instead of letting that be fully automatic.
If current load was handled by 3 blocks at a cycle, it could also process transactions in one second. The paralel blocks could run on staggered seconds, meaning 1 block per second. There also has to be an overlap of accounts between schedule lines, and a simple scheme to independently determine which witness should take the transaction where each schedule thread overlaps.
I will be thinking a lot about this schene yet. scalability and low latency at the same time is the goal.