I could be wrong but I thought miners were always in sync, miners are effectively writers to the ledger and single threaded. They all mine the same transactions in the same order. The first to find the hash with correct difficulty gets the block, which triggers the other miners to stop and verify. Once verified the new block becomes the seed for the next block. So the first transaction will always be processed before the second transaction. The second transaction would be committed as long as you had enough balance remaining after the first transaction.
how would it lead to more clearer code? You would have many interfaces referencing an instance variable, each with different semantics for that variable. Interfaces cant have variables so they should not be used as traits.
it isn't very good for aggregation of data. It doesnt provide core functionality that you need for analytics such as grouping, joining etc. The way to achieve this is to know what analysis you want to do before you store the data, which isnt practical for different types of analysis on the same dataset
Please don't use Java 8's default methods in interface's to do multiple inheritance, and code reuse. Prefering this over 'Util' classes is bad as it is inheritance over composition. The default methods were designed to facilitate easier interface migration
this seems like an ad for cassandra, many comments on how it scales and how partitioning is easy but no concrete examples at all. Having used cassandra in the past, it sure isn't the holy grail of nosql dbs, especially not for analytics that this article suggests