Ja, 2000 oder mehr TX pro Sekunde sind wirklich nicht schwer zu realisieren. Selbst für den normalen Rechner der zu Hause läuft:
Das sehe ich genauso.
Was wirklich problematisch ist, ist die ewig wachsende Blockchain. Um das zu lösen ist unbedingt sauberes Pruning notwendig. Deshalb ist es gut, dass der Fokus erst einmal darauf gelegt wird.
Ohne das könnte eine Erhöhung das TX Limits sehr schnell ein Schuss sein, der nach hinten los geht.
Soweit ich weiß, ist das Pruning bereits fertig und wird im offiziellen Client auch schon genutzt. Was der offizielle Client noch nicht macht, ist die nicht mehr benötigten Blöcke zu löschen (bzw. gar nicht erst zu speichern). Die Devs haben bisher noch Angst, dass es eben nicht genug der "Archival"-Nodes gibt, die zum Bootstrap (und nur dazu,
nicht zum Betrieb!) gebraucht werden. Allerdings könnte ich mir vorstellen, dass in Zukunft entsprechende Dienstleister diesen Job übernehmen und die Block-History zum Bootstrap gegen eine Gebühr anbieten. Auch ein P2P-System zur Vorhaltung der Blöcke ist denkbar. Dabei speichert dann natürlich nicht jeder Node alle Blöcke (das haben wir ja schon) sondern zum Beispiel jeder Node nur jeden 5ten Block.
At very high transaction rates each block can be over half a gigabyte in size.
It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.
Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.
The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. It is quite possible that the set will always fit in memory on dedicated server class machines, if hardware advances faster than Bitcoin usage does.