You are viewing a single comment's thread from:

RE: Exploring Steem Scalability

in #steem7 years ago (edited)

Sorry, but I think you are misunderstanding some of the technical aspects here. There are two different things being discussed.

If you are talking about DPoS - then you are talking about consensus nodes. These are the nodes that keep the blockchain state updated, and ensure that all of the new blocks are 'valid'. These nodes are covered in the "witness and seed node" section. Everything that is required for the DPoS portion of Steem to run is contained in these nodes, and the post was very clear that these nodes do not require the state file to be stored in RAM.

The part that you are quoting is talking about "full nodes" which get into API calls. API calls are an application layer built on top of the blockchain consensus rules. These nodes require more RAM because of the way the code is currently implemented, but eventually (as stated in the post), this logic for all of the non-consensus API methods will be handled separately - through things like HiveMind, SBDS, and RocksDB.

If your concern is rewards pool abuse and spam - those are valid concerns, but they are not going to be resolved in the context of "addressing the scaling requirements of the blockchain". Fixing spam and abuse issues might slow down the growth - but the ever increasing growth of the blockchain problem will still always be there - so scaling is something that still needs to be addressed regardless of what is/isn't done to address spam and abuse.

Sort:  

It seems we've reached the TTL for this convo, which is fine.

See you in a year, if this is even still around. Then we'll talk.