It makes more sense if you’ve read The Extended Phenotype by Richard Dawkins, which Dawkins considers to be his greatest work. “Procession" Evolution "A cradle Earth, horizons unseen New world in thirst, for the arcane We are, singers of the gone We remember, as along came life”
9/7/2022Validator rewards in Polkadot/Kusama Idealy almost all rewards in Kusama/Polkadot would come from work done securing parachains, including work supporting XCMP. We should continue some rewards for relay chain block production and finality of course, but their levels shall be greatly reduced. We have several plausible archetectures for rewards along two axes, rewarding only tranche zero vs all tranches, and rewarding deterministically vs probabaistically. Reward all tranches for all candidates We'd rerun the approvals loop on-chain after approvals happened off-chain, which avoids requiring good randomness. We worry this looks heavy, so we'd likely do this as a system parachain, which adds complexity. Reward all tranches but only for random candidates We'd likely never do this since its our most complex option, do to both sampling code and running the full approvals loop, but it provides a mechanism for the relay chain to non-zero tranches.
12/22/2021We've found our Reed-Solomn crate to be considerably slower than we'd like. We'll use this over the short term since the crate was designed for our use case. This document outlines future work for more drastic improvements. See also: https://codyplanteen.com/assets/rs/gf256_prim.pdf Arithmetic Our simd-accel feature already implements $\mathbb{F}{2^{16}}$ using Screaming Fast Galois Field Arithmetic Using Intel SIMD Instructions by James Plank, Kevin Greenan, and Ethan Miller. It builds upon $\mathbb{F}{2^4}$ because SIMD prefers 16-by-16 tables. We should check if this code actually produces reasonable assembler, which maybe rustc churn breaks. Syed wants to try plugging in the gf-complete code directly.
2/17/2021Polkadot should scale linearly in the number of validators, well once parachains work, including direct UDP connections between validators. We impove security if we diversify our validator operator pool too. We therfore want W3F to invite fresh-but-good validator operators into the communite and nominate their nodes, but this risks W3F being slashed. It's impossible to mitigate slashing risk while staking unknown people (see slashing section below). We could vet new validators whom we stake, and we should do some of this, but vetting becomes time intensive. Instead we should vet validator operators using their past public activity on peer-to-peer networks, which for diversity should ideally lie not be crypto-currency networks. There are three enormous peer-to-peer networks that fit this critertia, Tor, I2P, and Bittorrent. We'd presuably start new operators on a test network, or Kusama, and then graduate them to Kusama and Polkadot. Tor Tor provides a near perfect resource here. Tor actively avoids node hosting infrastructure homogenaity, ala EC2, etc., so Tor operators bring hosting diversity and thus security. Tor spends considerable effort teaching operators about basic operational security for peer-to-peer nodes. Tor even educates operators about interactions with law enforcement. Also, Tor operators can be solicited via Tor's mailing lists.
2/16/2021