It would be great to get developer input based on professional experience and any testing that has been done. i.e.: hardware of capacity X can perform to a level Y. I suspect that a RasPi would be CPU-limited first, then disk, then network. A desktop-class machine with spinning disk could be disk-limited first, then network, then CPU. With an SSD, it may be network-limited (assuming a residential connection).
There are other factors, too, such as simply downloading and validating the blockchain. i.e.: if the lowest common denominator is a RasPi and it can only do 10 tps, perhaps we can only run the network at 5, so that a node actually has the ability to ācatch upā and be able to mint in the first place.
I feel that the risk for them to be excluded exists, yes. Shareholders running on RasPi should be aware. I will be prepared to bring sufficient hardware and connectivity to keep minting up to the design capacity of the protocol. I do foresee the need to invest in an array of SSDās to keep up with the I/O needs, as well as needing to get business-grade connectivity.
Can you educate me on this 25% fill idea further?
I concur that this is another responsibility that the shareholders have, and perhaps this is bringing larger awareness to that.
I think the difference is in how it is implemented. It sounds as if you are advocating a new type of voting that is part of the protocol, whereas I was advocating more of a āstepā function that would be implemented thru code. Once any change is implemented once by a senior developer, I would think it be straightforward for a junior developer to see the code diff and compile a new client.
