T8493

Member
  • Content count

    1,384
  • Joined

  • Last visited

  • Days Won

    9
  1. You need just hashes and not necessarily original key values (Bloom filter can use the same hash function as NuDB).
  2. Ok, that's true. But disk capacity is not unlimited and you can store only a certain number of (key, value) pairs on disk before you run out of space. My point was that it is possible to use Bloom filter that is large enough that it behaves reasonably well even if you approach the maximum number of (key, value) pairs. You don't necessarily have to resize it afterward. I think that some other key-value stores don't resize it either. And you don't even have to persist Bloom filter on disk if you can tolerate startup costs. Startup costs are probably not so huge - all you need is to read all possible keys, which can be probably done in second or two on modern SSD disks (because you just read the index file sequentially). CPU costs of maintaining Bloom filter in memory are not so high because you can probably reuse the same hash value that will be used by NuDB anyway. So the only real cost that remains is several accesses to main memory.
  3. Why couldn't it all fit into memory? If you have billion keys (10^9) and false positive rate around 0.2, you need around 3 bits per key. That's 10^9*3 bits or circa 375 megabytes. This certainly won't fit into L1-L3 caches, but it would still fit into memory.
  4. Why doesn't NuDB use Bloom filters to check whether the key exists (before hitting the disk)? Bloom filters seem to be a relatively standard solution in (distributed) key-value stores.
  5. Didn't RL say no when you asked them if you could open-source it?
  6. However, libraries that are in production use cannot rely on teams with bus factor 1.
  7. I think it would be more useful if this library was written in C and not C++. C code can be easily called from other languages, but not C++ (there is no standard C++ ABI).
  8. RL could also open source other libraries written in .NET.
  9. For starters: RL will first have to make clear which libraries will be maintained in the future and which will be abandoned (like C# .NET library and plethora of other repositories). We have only one high-level library (RippleAPI) which is written in javascript. Currently, there is no officially supported way of using this library in other languages. Ripple-REST was abandoned, the library that sits on top of RippleAPI and enables external access to RippleAPI is unsupported. This new C++ library will probably implement just serialization in signing, but not other things (e. g. transaction submission). RL will also have to provide a way to download historical ledgers/transactions. Querying rippled for each old ledger and each old transaction can take months. RL will also have to provide more documentation about everything, including the repositories like ripple-historical-database.
  10. What is RCL trading API? RippleAPI or rippled API?
  11. Volume doesn't tell the whole story, especially because volume on Poloniex is currently high compared to what it was several months ago. Still, when I look at orderbooks of some popular gateways, the bid side is almost empty near the tip of the orderbook. Take a look at: https://charts.ripple.com/#/markets/XRP/USD:rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B?interval=5m&range=1d&type=candlestick or https://charts.ripple.com/#/markets/XRP/EUR:rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq?interval=5m&range=1d&type=candlestick Even a non-whale can easily push the price below $0.006 and it is almost impossible to sell more than 1 or 2 millions of XRPs without significant slippage (>3%).
  12. If no one providing liquidity on RCL, then you don't compete with anybody.
  13. https://techcrunch.com/2017/03/19/ibm-unveils-blockchain-as-a-service-based-on-open-source-hyperledger-fabric-technology/
  14. GateHub isn't an exchange. It is a gateway and its volume is probably included in the "Ripple Gateways" category.
  15. Not necessarily. Ripple Labs could redirect a certain amount of XRP sales to providing buy-side liquidity. Buy side liquidity could also naturally improve if price rises and there is a positive outlook on the future of XRPs (for example, we had much more buy side liquidity than now when the price was > $0.01).