| # Custom key mappings | |
| map n scrollDown | |
| map N previousTab | |
| map e scrollUp | |
| map E nextTab | |
| map i scrollRight | |
| map I goForward |
I've put together these notes as I read about DHT's in depth and then learned how the libtorrent implementation based on the Kademlia paper actually works.
400,000,000,000 (400 billion stars), that's a 4 followed by 11 zeros.
The number of atoms in the universe is estimated to be around 10^82.
A DHT with keys of 160 bits, can have 2^160 possible numbers, which is around 10^48
| var hypercore = require('hypercore') | |
| var ram = require('random-access-memory') | |
| var feed = hypercore(ram) | |
| feed.append('hello world') |
| start() | |
| async function start () { | |
| const promises = [ | |
| new Promise((resolve, reject) => setTimeout(reject, 1000)), | |
| Promise.reject(), | |
| Promise.reject() | |
| ] | |
| for (const a of promises) { |
Edit: here you can find our research paper describing the protocol more in-depth.
zkCoins is a novel blockchain design with strong privacy and scalability properties. It combines client-side validation with a zero-knowledge proof system. The chain is reduced to a minimum base layer to prevent double spending. Most of the verification complexity is moved off-chain and communicated directly between the individual sender and recipient of a transaction. There are very few global consensus rules, which makes block validation simple. Not even a global UTXO set is required.
In contrast to zk-rollups there is no data availability problem, and no sequencer is required to coordinate a global proof aggregation. The protocol can be implemented as an additional layer contained in Bitcoin's blockchain (similar to RGB[^5] or Taro[^6]) or as a standalone sidechain.
The throughput scales to hundreds of transactions per
| use futures::StreamExt; | |
| struct Response { | |
| inner: flume::Receiver<u64>, | |
| total: u64, | |
| sum: u64, | |
| } | |
| impl Response { |