It's basically BerkeleyDB Java edition, probably BDB High Availability (HA) Edition with some layers on top.
They're doing pre-sharding with ranges mapped onto replica groups, which are probably BDB HA instances. Since BDB supports transactions, they claim transaction support. But it only works if your keys fall in the same replica group (see other comment in thread). (Nothing wrong with that.)
There's no mention of shard migration, so they probably don't support it right now. (Shard migration is hard to get right.)
It's Java only.
BDB HA uses something which is said to be like Paxos, so they're claiming that (although they only mention it for master election), but they also have other consistency modes, which is interesting.
Looking at the plots:
Running on 32 replica groups (96 nodes) they were able to get 350K insert/sec, which is ~10K/s per replica group, with 1K values that is 10M/s per replica group. That means the local BDB instances just wrote everything to the log files, good luck with that. That's assuming they were running BDB in transactional mode, which is the only mode that actually keeps your database intact in case of a crash.
According to the 10M/s figure, it should have taken them 1.8 hours to load the data. According to the latency number, it should have taken 91 hours, so one of them is wrong. Probably the latency numbers, they were probably batching ~100 inserts and that's what the latency numbers are for.
In my NoSQL startup, our first product used BDB as the disk backend. In our second product iteration, getting rid of BDB was one of the major driving forces. I wouldn't touch it with a ten foot pole.